Slow rendering

[Kartoffelbreili]

I am having an issue with a very busy pdf that is very slow to load when zoomed in quite far. It is a map that has quite the details. On my phone i can zoom in wildly (Librera FD) and it renders basically instantly. Bundeswasserstraßenkarte Is there something that can be done about that? I noticed that firefox has this issue too and its even worse than on Sumatrapdf

[GitHubRulesOK]

hmm charts such as aeronautic / marine etc. are often highly compressed with "dangling" or highly "segmented" vectors that still need to be drawn for when zooming in, and in fact many of the text is complex vectors rather than all fonts, so agree this one looks slow (around 5 seconds here)

DisplayModel::BuildPagesInfo started DisplayModel::BuildPagesInfo took 0.00 ms StartMonitoringDirForChangesAPC() C:\Users\Administrator\AppData\Local\SumatraPDF Slow rendering: 4778.63 ms, page: 1 in 'C:\Apps\Programming\DBWK1000_Generaldirektion.pdf'

even removing contents by "optimising" (so half the size) does not improve it drastically half size still takes more than half the previous as its still 3 seconds. NotifyAboutFile: ignoring 'C:\Users\Administrator\AppData\Local\SumatraPDF\SumatraPDF-settings.txt' Slow rendering: 3214.20 ms, page: 1 in 'C:\Apps\PDF\DBWK1000_Generaldirektion_Optimized.pdf'

even decompressed (to attempt speedier reading) its still slow Slow rendering: 3213.49 ms, page: 1 in 'C:\Apps\PDF\DBWK1000_Generaldirektion_Optimizedb.pdf'

The main problem seems to be shear amount of data.

@kjk any more detailed feedback ? as it seems very slightly faster in MuPDF-GL

[GerHobbelt]

Sounds a lot like another mupdf issue PDF I've seen a few years ago (long standing issue at Artifex/mupdf, which is the library at the basis for SumatraPDF pdf viewing)

That case was (IIRC) a seascape map page produced as PDF with lots of contour/height lines; the problem was/is inside the mupdf library itself which took a proverbial aeon to render that file thanks to a extremely deeply nested "drawing context" stack in the PDF drawing instructions, which took an age because mupdf would create a new bitmap layer (heap allocation so you'ld also see a huge memory footprint BTW) and then, after drawing a bit of contour and the PDF data stream instructing it to "pop" the layer again after having drawn a few lines or a bit of shape, mixing that tiny bit of drawing into the parent layer. (repeat ad nauseam) Do that 10s of 1000s (!sic!) of times for a single page render and even the fastest computer is bogged down into shuffling huge quantities of bitmap data around.

(Note: a "side effect" then was the observation that mupdf easily gobbled up to 500GB and beyond to render a single pdf page to screen.)

Anyway, as I monitor their git repos, recent (this year) work over at Artifex showed they have been attending to this issue lately, but I have yet to test their patch due to hardware corruption and extraneous circumstances on my side. 😞 My own mupdf copy/fork has extra patches to prevent this from happening by, ultimately, brutally aborting a page render when "it takes too long": a nasty heuristic to ensure this kind of crap-up doesn't last so long we're off to a user panic (WTF is happening here?!) as in my application(s) these page renders can happen in the background and this sort of thing is pretty nasty re "predictability" of batch processing behaviour ("what's the bloody holdup? and why is the batch processor stuck?" [due to out-of-heap-mem crashes, but that's often far from obvious /why/])

The work done by Artifex this year was about optimizing that context stack push/pop handling, by NOT copying the bitmap for every drawing stack frame, but my own investigation into this issue 2 years ago proved it is a hard problem to crack -- and the Artifex patch I saw is not covering all corners, I fear, as it was, IIRC, an optimization for fully transparent layers. Sorry, I realize I'm sounding vague here. 😅

I need to dig to find the commits and references, but this is my 2 cents... (off seeing if I can dig up those refs for y'all)

PS: 👍 thanks for posting the link to your troublesome PDF as I'm always interested in bothersome PDFs in relation to mupdf (not related to SumatraPDF, but on the same page there, so to speak 😉 as this is (with very high probability) a mupdf issue.)

[GerHobbelt]

Found the bug I remembered, which seemed related to this (that one is fixed, though):

• https://bugs.ghostscript.com/show_bug.cgi?id=701945
  • Originally reported against SumatraPDF: https://github.com/sumatrapdfreader/sumatrapdf/issues/1030

[kjk]

It renders in about 3 secs in pre-release. It's not terrible given that it is a complex vector graphic.

If you feel it's still too slow, you can open a bug with mupdf: https://mupdf.com/

[GerHobbelt]

Thanks 👍,

And my respect for keeping Sumatrapdf up the way you do.

Cheers,

Ger

On Wed, 13 Sep 2023, 22:05 Krzysztof Kowalczyk, @.***> wrote:

It renders in about 3 secs in pre-release. It's not terrible given that it is a complex vector graphic.

If you feel it's still too slow, you can open a bug with mupdf: https://mupdf.com/

— Reply to this email directly, view it on GitHub https://github.com/sumatrapdfreader/sumatrapdf/issues/3517#issuecomment-1718245444, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADCIHXG7SJIG5YT44JZLLDX2IGXFANCNFSM6AAAAAAYRLVO6Q . You are receiving this because you commented.Message ID: @.***>