#160 WebP pages decode ~2.7x slower than PNG of equal resolution, causing lag when paging through comics/manga

[zchronos]

Summary

When a CBZ archive contains manga pages saved as WebP, paging through it in MComix feels noticeably laggier than the exact same pages saved as PNG at the same resolution. This is reproducible on the latest release (3.2.0) and is not fixed by having gdk-pixbuf's native WebP support available - the slowdown happens in Pillow's decode path, not because of a missing loader.

Environment

• MComix version: 3.2.0 (also reproduced on 3.1.1)
• OS: openSUSE Tumbleweed 20260724
• Kernel: 7.1.4-1-default (x86_64)
• CPU: Intel Core i7-13700HX (24 threads), 32 GB RAM
• Pillow: 12.3.0
• libwebp (as used by Pillow, via PIL.features.version('webp')): 1.6.0
• gdk-pixbuf on this system also has native WebP support (shows up in Pixbuf.get_formats()), so this is not a "missing loader" situation

Steps to reproduce

1. Take a manga page saved as lossy WebP at a typical scanlation resolution (4000-8000px range).
2. Export the exact same page losslessly as PNG for comparison.
3. Call mcomix.image_tools.load_pixbuf() directly on each file (the same function MComix itself calls when displaying a page) and time it. Script attached to this ticket (bench_mcomix_load.py).

Benchmark data

Median of 3 runs each, calling mcomix.image_tools.load_pixbuf() directly (the real MComix code path):

| Page | Resolution | WebP size | WebP load | PNG size | PNG load | Ratio |
|---|---|---|---|---|---|---|
| page01 | 4312x6065 | 3.88 MB | 1.047 s | 16.29 MB | 0.376 s | 2.78x |
| page02 | 4225x6065 | 2.67 MB | 0.858 s | 10.48 MB | 0.321 s | 2.67x |
| page03 | 8270x6065 (double-page spread, ~50MP) | 6.28 MB | 1.806 s | 26.25 MB | 0.647 s | 2.79x |
| page04 | 4225x6065 | 2.74 MB | 0.880 s | 12.09 MB | 0.318 s | 2.77x |

Average ratio: ~2.75x, and it stays essentially constant across this resolution range (including the ~50MP double-page sample), rather than growing disproportionately at higher resolutions. Note the WebP files are consistently much smaller on disk than the PNGs, so this isn't an I/O effect - it's purely decode CPU cost.

Likely root cause

load_pixbuf() in mcomix/image_tools.py tries PIL.Image.open() first for every image regardless of format, and only falls back to GdkPixbuf if that raises. Since Pillow here is built with WebP support (libwebp 1.6.0), WebP pages are decoded through Pillow's libwebp binding. This looks like an inherent cost rather than a bug in MComix's format handling: WebP's VP8/VP8L decoding is more CPU-expensive than PNG at comparable resolutions, and at a consistent ~2.7x multiplier it's very noticeable at the 4000-8000px page resolutions common in scanlated manga releases - not just at extreme outlier resolutions.

(A related-sounding complaint about very high-resolution images was filed against the now-archived multiSnow/mcomix3 fork - https://github.com/multiSnow/mcomix3/issues/159 - describing much worse degradation above ~7000px. My data above doesn't show that kind of cliff, so it may have been a separate/already-fixed issue in that older codebase; I'm noting it only for context.)

Possible directions (for discussion, not a demand)

• Decode upcoming/previous pages on a background thread pool sized to available CPU cores, so the ~2.7x WebP decode cost is hidden by prefetching rather than felt when actually turning the page. I see "Maximum number of concurrent extraction threads" and "Maximum number of pages to cache" in Preferences, but I'm not sure whether page decoding itself is parallelized independently of archive extraction.
• An opt-in local cache that pre-decodes/re-encodes WebP pages to a faster-loading format the first time an archive is opened.

I'm happy to help benchmark any proposed approach on my machine, and to attempt a patch myself if that would be welcome - just let me know if there's a preferred way to submit one (patch attached to this ticket vs. a merge request against the git repo).