Problems with big files not presenting pages correctly (Black screen, can't draw the page, etc)

[Hilarioma]

Hello I am using SumatraPDF for long time and found it very usefull. It is like my Swiss Army Knife ;-)
But recently I began to use bigger files in .cbz and .pdf (I am comic reader)
and found it is having trouble to show some pages.
Sometimes it shows an oversised image. If you check the file with another viewerno problem.
https://i.imgur.com/3apmw7q.png
Other times it is just Black screen, nothing appearing (basically on .cbz files)
and other times just a white page with a message "Can not draw the page" (Or a phrase that means this)
https://i.imgur.com/co00tdt.png
The problem appears with Big files (over 400 MB)
Any suggestion to solve this? Perhaps some variable in the config file.
Thanks for any help

By the way My system is:

• Windows 11 Pro - 22H2
• 12th Gen Intel Core i5-12600K 3.70GHz
• 32 GB Ram

[GitHubRulesOK]

Both those images are not supported by your links !!! and thus is unlikely a variable in image apps is available as the formats can have limitations that other apps exceed and might in some viewers be tolerated in some fashion

perhaps try upload examples to https://transfer.sh ?

[Hilarioma]

OK. Here are the screen captures

https://transfer.sh/tFgMp4/SumatraPDF_uS7RamQ9li.png

https://transfer.sh/roYJ3e/SumatraPDF_qXxYxAF90N.png

[kjk]

Can't render file is most likely caused by running out of memory.

But really can't do anything without a test file, see https://www.sumatrapdfreader.org/docs/How-to-submit-bug-reports

[Hilarioma]

This is probably Memory problem because the problem is repeatable with a file over 1 GB.
with lower sizes, some times I get problems, other not.

1. Do you want I send you the file? Where do you want I upload it?
2. I followed your link but I haven't found how to generate some kind of dump or error log to give you more info.
   Regards

[kjk]

You can e-mail me the file to kkowalczyk@gmail.com or upload to transfer.sh and e-mail me the link.

[Hilarioma]

Hello, here is one file generating the problem as soon as I load it on sumatrapdf. https://transfer.sh/9MD7hr/Le%20triangle%20Secret%20-%20Lacrima%20Christi%20-%20Integrale%20%28T01-06%29%20%28Glenat%202021-10%29%28Convard%20-%20Falque%29%28TONER%29%283917%2C%20423dpi%29%28BD%20FR%29.cbz thanks El lun, 20 mar 2023 a las 21:38, Krzysztof Kowalczyk (< ***@***.***>) escribió:

…

You can e-mail me the file to ***@***.*** or upload to transfer.sh and e-mail me the link. — Reply to this email directly, view it on GitHub <#3365 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGPSYF7LUFQL22XF7LHPKT3W5C52ZANCNFSM6AAAAAAWBNMQTI> . You are receiving this because you authored the thread.Message ID: ***@***.*** .com>

--

[kjk]

I tried this 1.2 GB file on my 32 GB RAM laptop with latest pre-release (https://www.sumatrapdfreader.org/prerelease).

I flipped through all the pages and they all rendered.

But we do use 2 GB of ram so it's still most likely it ran out of memory - it depends on how much memory other processes use.

You can check with task manager (Ctrl + Alt + Delete) to see how much free memory there is (I have about 12 GB free).

Also when you get that error, you can use show log command from Command Palette (Ctrl + K). Maybe there's more info about why it failed.

We could improve this .cbz files. I think we keep the .cbz file (or all decompressed images) in memory. We could decode on demand, but that's a trade off: it'll be slower to render pages if they are not in memory.

[GitHubRulesOK]

sumatra-log.txt
Processor Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3401 Mhz, 4 Core(s), 8 Logical Processor(s)
Installed Physical Memory (RAM) 8.00 GB

I loaded the File in MuPDF for compare it seems only slightly slower to traverse page by page (perhaps a fast disk on this device) but memory usage is considerably lower more like under 20 MB rather than 2000 MB ??

[kjk]

Yeah, like I wrote above, most likely the difference of keeping stuff in memory vs. on disk.

[Hilarioma]

Thank for your help.
I did some more tests
Last week I clean my system, and unload some residents softwares - scanners drivers,etc-
Today I am running sumatra with the file and don't have pages staying in black.. just SLOW display

sumatra-log-20230330.txt
in the log I find many SLOW RENDERING messages

I have made another test with MuPDF and what I find is it is much faster tha sumatrapdf..
I don't understand very well because from @kjk explanation, I understood the file is in memory for sumatrapdf but not in MuPDF
and this is why it take more memory in sumatrapdf than in mupdf.
Then the previous should be faster than the second one.. but this is not the case..
Hope you can bring light to this issue.

[GitHubRulesOK]

wow decompressed 1 page of 348 = 58.28 MB (61,110,440 Bytes) even the most compressed blank page says 58.28 MB (61,110,440 Bytes) why?
A blank page in theory would only need 0 bytes and a few to say I am blank.

As a lossy jpeg its 117KB as an empty PNG it will be 71KB as gigantic when compressed

[Hilarioma]

Thanks for all the comments.
I understand this file may have an "escesive resolution". In fact it surprise me how much zoom I can do on these pages without loosing quality. And then it can be pointless to use so big file when you have a 10" screen on a tablet.
But you know how things evolved in computing..... year ago 750 MB was enough for viewing a film. Today you find files in escess of 12 GB for just a film.
With comics, we are having the same process. Years ago we have scanners with little capacity, and today scanning has improved a lot.

Having said that, what I am trying to understand is the situation with this file even if it is not reasonable to use this resolution in the majority of the cases.
What surprise me is how fast work mupdf (I never heard about this viewer before @GitHubRulesOK comment it). I wonder how is it possible if it not load the full document in memory.

I understand SumatraPDF load everything in memory and this can be one limitation for beeing faster.
and I understand with this approach, I allway will have a problem with big big files.
I am not suggesting to change the approach, just may be, getting some kind of message telling "your resources are not enough to view this file) or something like this.
Or just to know if there is anyway to optimize sumatraPDF to improve reading this files.
Thanks all

[GitHubRulesOK]

I agree there are ways to improve timings HOWEVER take the "biggest" page on its own, at "actual size" in a graphics app, and compare with an alternate. So size is maintained but density reduced by half (zoom is thus doubled) Colours/Compression Quality increase due to interpolation, but time to render is significantly smaller reduced from 188 ms to 63 ms so 3 times faster (related more to disk size say 6:2) and memory requirement is 1/4 as much. Visually there is little difference apart from a purists slight drop in definition.

[Hilarioma]

Thank you for the test. Interresting to learn. I will do more tests and see what I have to do with this big files.

[GitHubRulesOK]

@Hilarioma Linking to #3411

[Hilarioma]

Thanks for the info @GitHubRulesOK . I tried to understand.. but this is on another level than my basic understanding ;-)
Seams an interresting plan. I will keep an eye on it.

[kjk]

I've lowered memory usage on this file from ~2 GB to ~700 MB in pre-release 15430 or later.

Still can be improved.

[emmayashri]

SumatraPDF running out of memory seems likely with such large files. Compressing images to reduce size can help improve performance. You could use JPEG Compressor to compress without losing quality, making it easier for Sumatra to handle bigger files.

[GitHubRulesOK]

@emmayashri SumatraPDF has to use DEcompressors NOT Compressors hence the issues, as images need to become raw pixels for viewing not the binary encoded compressed data.

note 35 ms= 0.035 seconds (roughly 30 pages per second)

LoadDocument: 35.22 ms, 1 pages for 'C:\Users\K\Downloads\wp300.png'
tab: TabsCtrl::InsertTab 0: tabHighlighted: 1 (was 0)
tab: TabsCtrl::InsertTab 1: tabHighlighted: 2 (was 1)
DisplayModel::BuildPagesInfo started
DisplayModel::BuildPagesInfo took 0.00 ms

The less compression the better the quality and faster it shows after decompression so the closer to a working size.

SumatraPDF is designed to produce as good a lossless image as it was before compress.
Lossy JPEG simply makes image worse to load (slower to unpack) and worse to view (quality loss due to clumping colours into communal blocks).