Bug 337209 - Memory protection for big pixmaps needs updating, be more smart
Summary: Memory protection for big pixmaps needs updating, be more smart
Status: RESOLVED FIXED
Alias: None
Product: okular
Classification: Applications
Component: DjVu backend (show other bugs)
Version: 0.19.2
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-07 23:19 UTC by Matteo Italia
Modified: 2021-03-10 08:35 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
A djvu file that exposes the problem at 152% of zoom (138.90 KB, image/vnd.djvu)
2014-07-07 23:19 UTC, Matteo Italia
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matteo Italia 2014-07-07 23:19:17 UTC
Created attachment 87634 [details]
A djvu file that exposes the problem at 152% of zoom

As in title. With all Djvu files I have (some downloaded from the Internet, some created just to check this issue with pdf2djvu*), zooming more than ~150 % results in a white image being displayed instead of the actual (zoomed) file content; zooming back the page is rendered correctly.

I say ~150% because, depending on the files, it seems that there are some variations in the exact zoom level, probably it's related to the zoom level relative to the actual pixels stored inside the Djvu page.

I attach a document that exhibits the problem (in this case, on my machine at 152% of zoom).

* pdf2djvu --version reports "pdf2djvu 0.7.17 (DjVuLibre 3.5.25, poppler 0.24.5, GraphicsMagick++ 1.3.18, GNOME XSLT 1.1.28, GNOME XML 2.9.1)"
Comment 1 Matteo Italia 2014-07-07 23:21:28 UTC
Almost forgot: I'm using the KDE distribution from KUbuntu 14.04, but the problem may be present since before (I'm not sure, but I recall seeing it also on a machine with Ubuntu 12.04; tomorrow I'll check).
Comment 2 Yuri Chornoivan 2014-07-08 19:04:11 UTC
Confirmed for Okular git/master, DjVuLibre 3.5.25.
Comment 3 Albert Astals Cid 2014-07-09 23:27:39 UTC
It would result in a too big pixmap and our memory protection kicks in

okular(19540)/okular (app) Okular::DocumentPrivate::sendGeneratorPixmapRequest: Running out of memory on page 0 (3975x5624 px);
okular(19540)/okular (app) Okular::DocumentPrivate::sendGeneratorPixmapRequest: this message will be reported only once.

But the thing is that this check is kind of stupid and should be improved to take into account total system memory, free memory and stuff.
Comment 4 Matteo Italia 2014-07-10 00:16:14 UTC
Actually, doesn't Okular have some kind of tile-manager mechanism built-in, used for the pdf backend?
If so, the right thing™ would probably be to adapt the Djvu backend to use tiles (instead of a single huge rescaled image), so even in the worst case the minimum memory needed for any level of zoom would be just a small multiple of the display area size.
Comment 5 Albert Astals Cid 2014-07-10 20:32:10 UTC
It does, but does the dvjulibre library support only rendering parts of the file? Anyway that's a different feature to this, if you want to request a wish for it, please do :)
Comment 6 Pino Toscano 2014-07-10 20:36:33 UTC
(In reply to comment #5)
> It does, but does the dvjulibre library support only rendering parts of the
> file?

Yes, it does. It is even used to not make djvulibre render more than 1500x1500px-big tiles, composing the pieces in case of page sizes bigger than that.
Comment 7 Justin Zobel 2021-03-09 23:59:33 UTC
Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.
Comment 8 Matteo Italia 2021-03-10 08:35:38 UTC
Hello, just tried with Okular 1.3.3 (KDE Frameworks 5.44.0, Qt 5.9.5, DjVuLibre 3.5.27.1-8ubuntu0.2).

I tried again with the file I attached originally, and the problem seem to be resolved, I can zoom up to the maximum level (400%) and pan around without issues (although the zoom itself is a bit jerky). I repeated the test with all the "memory footprint" settings and the results are similar. I think we can close this as resolved.