KillerPDF 1.9.0 "Overkill": development is open

[SteveTheKiller]

KillerPDF 1.9.0 is Overkill, and the development branch is now public.

I'm opening this branch to PRs for just about anything: new features, new tools, engine improvements, performance work, UI and workflow changes, bug fixes, translations, documentation, and experiments. If there's something you've wanted KillerPDF to do, this is a good time to get involved.

The first big change is already in: PdfPig has been removed. The KillerPDF.Engine now handles text and image placement extraction as well as document reading, editing, and writing. PDFium still handles rendering.

A few guidelines:

• Target dev/1.9-overkill for 1.9 PRs. Base your work on that branch. main stays on the 1.8.x maintenance line.
• You don't need an assigned issue or advance permission. Draft PRs and work in progress are welcome. For a major redesign, new dependency, or something that could take weeks, start a discussion early so we can work through the direction together.
• Keep each PR focused. A substantial feature is fine; unrelated changes are easier to review separately.
• Show what changed and what you tested. Screenshots help with UI work, and a small sample or regression test helps with PDF behavior. Say plainly if something hasn't been tested.
• Build on what's already here. Reuse the existing themes and controls, keep the engine independent of the desktop UI, and preserve document safety.

I'm deliberately leaving the scope broad while Overkill develops. Everything still gets reviewed, and not every idea will land in 1.9, but you don't need to limit yourself to small fixes or an existing checklist.

This is an active development branch, not a stable release. The plan is to build out and stabilize 1.9 before moving into the cross-platform 2.0 work.

The contribution guide has the build instructions and testing details. Feel free to use this discussion to pitch an idea, coordinate work, or ask where to start.

[Ryokoxx]

Good to see it open.

I'm in, but not straight away.
I'm tight for time at the moment and it'll be a few weeks before I can put proper hours into it, so I'll say that now instead of volunteering and then going quiet on you.
When I've got clear air I'll take something off the milestone and tell you which one before I start.

Matt

[SteveTheKiller]

No worries, we're going to take our time with this one, getting it right.
We'll maintain 2 branches for now.

Changes that make it into main will also be merged into Overkill.
I do have a 1.8.4 update waiting but I'm in no hurry to release it yet and think we should wait a bit to accumulate more fixes.

I really like where this app is headed and we're already ahead of schedule. I'm also looking into replacing Tesseract in 1.9, and maybe even Pdfium... we'll see. Getting those dependencies removed would make 2.0 a breeze.

[SteveTheKiller]

Dependency removal is underway.
I would like to remove as many dependencies as possible.
1.8 removed PDFSharp, and so far in 1.9 I have removed PdfPig.
I am currently removing Pdfium and Tesseract.

When I am done, the engine itself will be able to do everything, and there will be a distinct barrier between the engine and the UI.
People could then use the engine for any project imaginable.
If I can get enough of this done before 1.9, then v2.0 should be a breeze.

I have a long weekend ahead of me to work uninterrupted now at least.

[SteveTheKiller]

I pushed a new testing milestone to dev/1.9-overkill.
PDFium is now gone, and the engine handles rendering too.
On the 649-file conformance set, it rendered 609 files with zero failures, compared with PDFium's 600 and eight failures.

Performance is getting close to 1.8.x, and engine-owned OCR is working, with Tesseract still available as a fallback.
If you build the branch, I'd especially appreciate troublesome PDFs, rendering differences, or anything that feels slow.

I still have tons of work to do on the engine, but it already supports tons of features that 1.8 doesn't so we can start thinking about how to wire it into the UI.

[SteveTheKiller]

Quick update on the new KillerPDF engine work:

The 1.9 development branch now renders 614 of the 649 conformance files, with 35 intentionally skipped and zero failures. PDFium 1.8.5 renders 600, skips 41, and fails on 8.

On the 600 files both engines render, KillerPDF.Engine currently takes 13.260 seconds versus PDFium at 11.707 seconds. That puts us about 13% behind PDFium, down from roughly 2.6x slower before this work.

The new renderer includes anti-aliased rasterization, improved clipping and stroke handling, cached image conversion, and much broader recovery for malformed PDFs. The full engine suite currently passes 3,068 tests, with another 338 application tests passing.

The current work is available on the dev/1.9-overkill branch for anyone who wants to look through it or try it. I would especially appreciate ideas around JPEG and JPEG 2000 decoding, rasterization, caching, allocation reduction, and other ways to close the remaining performance gap.

[SteveTheKiller]

Breakthrough: the new KillerPDF engine has reached rendering parity with PDFium in the real app benchmark!

On the 600 conformance files both engines render, the latest engine took 12.20 seconds versus 12.28 seconds for the PDFium 1.8.5 build. That's across three alternating runs at 1024 pixels. Run-to-run noise is about 5%, so I'm calling this parity, not a speed win.

The engine rendered 614 of the full 649 files, with 35 skipped and zero failures. PDFium rendered 600, skipped 41, and failed on 8. Whole-pass time was 24.21 seconds versus 23.21 seconds, about 4.3% longer while completing more files.

The biggest gains came from caching text glyphs, faster shading calculations, cutting allocations, and improving damaged-file recovery. Document-open time on the shared files dropped from about 3.7 seconds to 1.5 seconds.

The engine suite passes 3,113 tests. The other optimizations were pixel-identical on 190 sampled files; glyph caching can slightly change text-edge antialiasing. App testing has 333 passes and five tests still unverified because of a WPF FontCache exception in the test session. An older app payload failed similarly, but I haven't confirmed the cause yet.

I've pushed the work to dev/1.9-overkill, including the benchmark checkpoint and raw results.

This is still a development milestone. Next comes broader rendering validation and clearing the remaining test uncertainty. Parallel rendering is worth investigating separately, but I want to preserve rendering quality as performance improves. Troublesome PDFs and real-world rendering comparisons are especially welcome.

[SteveTheKiller]

The latest KillerPDF 1.9 Overkill development checkpoint is pushed.

Some verified progress:
4,424 automated tests passing: 4,054 engine tests and 370 application tests.
674 pages rendered successfully across the latest comparison sets.
19% lower peak memory than the previous PDFium pipeline on the 600-page shared set: approximately 495 MiB versus 614 MiB.
7% to 9% faster rendering on a JPEG 2000-heavy test page after the latest sample-conversion optimization, compared with an earlier 1.9 build.
The latest optimization preserved pixel output across all 674 comparison pages.

But overall parity is still unfinished.
PDFium remains faster on both measured sets, and the difficult set uses about 6% more peak memory in 1.9. Some transparency and color differences also remain.

Development continues to focus on rendering accuracy, compatibility, difficult-page performance, and memory use.