Some .CBR files open extremely slower than others

[wjharing]

My comics are in .CBR/.CBZ file format.
I noticed that some .CBR/.CBZ files open a lot slower and it looks as if program is hanging (for 12 seconds!), before it opens correctly.

An example of such file is 70mb, so that shouldn't be the issue.
Some files might have subfolders in them, before the pages are listed. This shouldn't be a problem either I believe.

I did notice with one slow .CBR file, that the pages are numbered 001.jpg, etc, but that one of the page numbers is omitted. Would this be a reason why SumatraPDFReader struggles?

[GitHubRulesOK]

Rendering timings can vary considerably from version to version as the core code goes through many altered balance of demands on resources. So the only litmus test is current pre-release as that can be changed for any specific variability in behaviours.

Fastest time will usually only be achieved with local file on main (C:) drive.
However just tested a 19.5 MB (623 pages!) on a remote device L:\ and it appeared in about 3 seconds
allowing for transportation the log shows it was about 1 second to load.

LoadDocument: 43.77 ms, 623 pages for 'L:\!fromHP\Desktop\temp\continued-fractions.djvu_0623.cbz'
DisplayModel::BuildPagesInfo started
DisplayModel::BuildPagesInfo took 858.14 ms
EngineCbx::LoadBitmapForPage(page: 2) took 0.65 ms

However in order for there to be a change specific example files that demonstrate such lagging would be needed and GitHub imposes size restrictions.

[wjharing]

Sorry, I should have clarified, I was using the last pre-release version of 3.6. (but noticed with many previous 3.6 versions as well)

Log for accessing the .cbr that works normally:

CreateControllerForEngineOrFile: 'C:\!ncoming\2 test sumatra\20.000 Eeuwen onder zee - 02 - Het schuilhol van Cthulhu.cbr', 50 pages
uitask::WndProcTaskDispatch: will execute 'TaskLoadDocumentAsyncFinish', func 0x000001EF2C3C18E0
DisplayModel::BuildPagesInfo started
DisplayModel::BuildPagesInfo took 449.14 ms
EngineCbx::LoadBitmapForPage(page: 2) took 26.37 ms
Slow rendering: 109.62 ms, page: 2 in 'C:\!ncoming\2 test sumatra\20.000 Eeuwen onder zee - 02 - Het schuilhol van Cthulhu.cbr'
EngineCbx::LoadBitmapForPage(page: 1) took 3.27 ms

The log for accessing the .cbr that is opening with a 12s delay (freezing up):

CreateControllerForEngineOrFile: 'C:\!ncoming\2 test sumatra\20.000 Eeuwen onder zee - 01 - De gruwel in de storm.cbr', 49 pages
uitask::WndProcTaskDispatch: will execute 'TaskLoadDocumentAsyncFinish', func 0x000001EF2C3C2BE0
DisplayModel::BuildPagesInfo started
DisplayModel::BuildPagesInfo took 13610.73 ms
EngineCbx::LoadBitmapForPage(page: 2) took 64.12 ms
Slow rendering: 167.35 ms, page: 2 in 'C:\!ncoming\2 test sumatra\20.000 Eeuwen onder zee - 01 - De gruwel in de storm.cbr'
EngineCbx::LoadBitmapForPage(page: 1) took 42.10 ms
Slow rendering: 151.69 ms, page: 1 in 'C:\!ncoming\2 test sumatra\20.000 Eeuwen onder zee - 01 - De gruwel in de storm.cbr'

Hereby a link to both files.
https://gofile.io/d/FZh98J

[GitHubRulesOK]

Hmmm I must agree that using those files in different ways SumatraPDF seem slower however converted to PDF they seem much faster ! the file is larger as PDF but the speed seems good so for what it is worth that would be a workaround until pre-release fares better you can even use older portable SumatraPDF to do the job. https://filetransfer.io/data-package/PMKzbWAV#link
image.pdf was a test with other software for comparison and the smaller one is the pure cbr saved as PDF from version 3.1.2

When source images are jpeg then pdf can hold them "as is" with very little overheads as page objects

[wjharing]

When I unpack and repack that archive with the problem, the problem disappears.
rar info (unrar lt <comic.cbr>) from the 01 comic file (the file with the issue) shows RAR 1.5(v29) -m3 -md=4m
While the .rar info from the 02 comic shows RAR 1.5(v29) -m3 -md=2m
And when I repack, RAR 5.0(v50) -m3 -md=2m

I don't know if -md=4m is causing issues, given this has to do with memory, compression, cpu?

I checked your generated .pdfs, and those are rendering quick. But indeed a temporary workaround solution only. Hopefully the above info helps in any way?

[kjk]

the file is no longer available

[GitHubRulesOK]

@kjk
sorry have been at heavens door in hospital but they refused to keep me in , Cant be certain this was the file state at that time (had reduced to 049.cbz while OP said 50 pages), but should be similar enough the PDF was a trial run of mine the 049.cbz was from the OP source file.
https://filetransfer.io/data-package/r7k5jpuq#link

[GitHubRulesOK]

@kjk
OK think I tracked them down so same link as above there are 2 CBR files that were the likely source.

[wjharing]

It seems you have the files, but let me know if you need anything further to help identify the issue