very slow rendering for some pages in PDF

[GerHobbelt]

SumatraPDF version

• 3.5.2

Describe the bug / To Reproduce

open PDF, view pages as usual. Go to page 110 and observe Sumatra freezing while displaying the text "please wait - rendering..." for about 28 seconds on a fast, fully stocked and otherwise very lightly loaded AMD Ryzen / Win10 box.

The page, finally, shows up without obvious faults.

Hit PgDn key to jump to the next few pages, some of which will also exhibit this same 'extremely slow' behaviour.

Expected behavior

Well... 😉

File that reproduces the problem

PDF has been attached. (See further notes below.)

Screenshots
N.A.

Additional context

I know the engine (mupdf) had some 'takes a heck of a lot of time' issues with some sea geo-charts, which were PDF pages loaded with a humongous number of tiny vector drawing instructions. (Might that one be #3841 / #3842 in your issue lists, perhaps?)
I don't recall Artifex "fixing" that one down to sub-second render times (if that's possible at all, though I do recall Acrobat having no issue showing those charts quite swiftly), though at some point (IIRC, fingers crossed) there were mupdf commits that reduced the problem by a large margin (IIRC something about render stack push/pop instructions being optimized out for certain PDF layer start/end instructions).

Anyway, that was then (2023-ish), this is a new one.

Now this new PDF doesn't have anything looking like "lots and lots of vectors" in the offending pages, so it's probably only sideways related, hence new issue.

Apologies for not having run this through my own mupdf variant (dev focus is currently elsewhere, for me, sorry!), so I don't know what's going on exactly with this new 2026 PDF example.

Another thing I noted for this one: I tried to (quickly) produce a Minimal Sample PDF by deleting the first 100+ pages using NAPS2 and the resulting PDF was a horribly large 340 MByte, while this one is 'only' 37MB, so there's probably more going on in there...

Anyway, AFAICT, only 2-3 pages of the PDF exhibit this "veeeeery slow page render" behaviour, which also freezes the SumatraPDF UI.
I know you're using mupdf under the hood (👍) and IIRC the original Artifex codebase (my own mupdf is 'vendored' by various patches, so I'm not certain it was in the original as well) had a way to abort page rendering -- IIRC it could be accomplished via hooking the progress monitor and toggling a flag, but that's my shoddy brain and away from the dev box, so YMMV.
Anyhow, MAYBE you can find a way to abort page renders like these when users hit PgUp/PgDn keys to jump away? (That would mean rendering in a separate thread so I bet that's a non-trivial code change. Still, it would be nice to have. My own mupdf copy uses another approach, which is to become a very rough and shoddy renderer, ignoring/skipping many PDF render instructions (layer stacking, transparencies) once the time-to-render-this-page surpasses configured maximum duration thresholds: this approach works for me but required patching the mupdf engine in a couple of places and may not be acceptable for others as you'll end up with 'garbled' page images that way, naturally.) I have not checked this new PDF with my own engine yet, so I don't know if this one triggers something entirely different...

Thank you for maintaining a very useful and appreciated PDF reader -- I've ditched Acrobat and a few others as Sumatra also handles my ebooks (entertainment) quite well, so it's my one-stop-shop for document reading these days! ❤️

[GerHobbelt]

Failed to upload "very-slow-render-pp110-af.pdf" -- Grrrrr! 💢😠 ... one moment please...

[GerHobbelt]

Here you go: PDF at https://github.com/GerHobbelt/sumatra-mupdf-issue-5248

[GerHobbelt]

Update: tested with latest SumatraPDF beta:

Latest SumatraPDF pre-release build version 17127, built on 2025-12-31, commit 0d788abd6f3d447f4b0c5d1454b905140bc17970

Result: parts of the UI seem responsive, but page scrolling, etc. is still frozen and the long render time is still there.

Now that I look more closely, it looks like a #3841 candidate as this particular page has a bit of artwork in the background that looks like somebody pasted in a lot of (vector?) dots: see screenshot. If that was done using Illustrator or some of their ilk, in a hurry (see also the artifacts in the artwork), chances are this is output as (I'm guessing!) one vector render layer per dot and we're back to the old PDF render issue, with transparencies.

Alas, I thought mupdf had that one tackled in about 1.25 / 1.26 there-abouts, but apparently not. 😅 Blame my mangled recollection; or this turns out to be something else entirely after all anyway.

Screenshot:

[GitHubRulesOK]

there are at least 3 pages that are a problem and 110 will likely be similar to past page problems Slow rendering: 153.83 ms, page: 87 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 15118.63 ms, page: 110 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 125.56 ms, page: 36 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 208.92 ms, page: 56 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 328.67 ms, page: 58 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 139.80 ms, page: 59 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 7222.72 ms, page: 110 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 117.64 ms, page: 86 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 7054.28 ms, page: 110 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 9662.38 ms, page: 110 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'
Slow rendering: 100.51 ms, page: 114 in 'C:\Users\K\Downloads\very-slow-render-pp110-af.pdf'

[kjk]

There is one page (110) that takes 8-10 seconds to render. I profiled it and there's nothing obvious there. Maybe mupdf devs could see a way to avoid doing work for this particular PDF content.

However I can make an improvement in my rendering system. Currently that slow page delays rendering of other pages which is not good, but not easy to fix either.

[GitHubRulesOK]

If you Neuter the grey ever decreasing circles gradient background on 110 (these early messages were introduced by me flip an n to f in the index) then the other slower pages are less noticeable but 87 and 115 seem slow too.

syntax error: no XObject subtype specified
encountered syntax errors; page may not be correct
syntax error: no XObject subtype specified
encountered syntax errors; page may not be correct
syntax error: no XObject subtype specified
encountered syntax errors; page may not be correct
currTabIdx: 1
uitask::WndProcTaskDispatch: will execute 'SafeDeleteCommandPaletteWnd', func 0x0A97C688
uitask::WndProcTaskDispatch: did execute, will delete func 0x0A97C688
currTabIdx: 1
uitask::WndProcTaskDispatch: will execute 'SafeDeleteCommandPaletteWnd', func 0x0A7FD118
uitask::WndProcTaskDispatch: did execute, will delete func 0x0A7FD118
Slow rendering: 117.82 ms, page: 35 in 'C:\Users\WDAGUtilityAccount\Downloads\very-slow-render-pp110-af1.pdf'
Slow rendering: 113.84 ms, page: 57 in 'C:\Users\WDAGUtilityAccount\Downloads\very-slow-render-pp110-af1.pdf'
Slow rendering: 168.15 ms, page: 87 in 'C:\Users\WDAGUtilityAccount\Downloads\very-slow-render-pp110-af1.pdf'
syntax error: no XObject subtype specified
encountered syntax errors; page may not be correct
Slow rendering: 126.86 ms, page: 114 in 'C:\Users\WDAGUtilityAccount\Downloads\very-slow-render-pp110-af1.pdf'
Slow rendering: 201.54 ms, page: 115 in 'C:\Users\WDAGUtilityAccount\Downloads\very-slow-render-pp110-af1.pdf'
currTabIdx: 1

for what it is worth here is that file with now 0030237829 00000 f in trailer 7 days limit upload https://fileport.io/ew1aBST2Nn9r