GNOME Bugzilla – Bug 303365
increase zooming level
Last modified: 2018-05-22 12:58:24 UTC
Wouldn't it be possible to improve the top zooming level to at least 800% (when not 1600%)? Acroread 7 supports a 6400% zooming level.
This is hard-fix bug, but actually it's important. The problem is that evince backend should render a whole page, not only visible part of it. That requires a lot of memory, especially for big zooming level.
I would very much like to increase the zoom level. I often do things with *very* high precision, and the way that Evince reloads the document and keeps the same zoom level and page position is *AWESOME*. However, I would really like to see this zoom level increased as high as possible withough "killing" the computer ;)
Not going to happen for 2.12. Too much of a feature.
*** Bug 313176 has been marked as a duplicate of this bug. ***
I don't understand why evince (splash backend) requires so much memory. GPDF renders documents antialiased faster and its 800% zooming is reasonably fast. I like evince a lot, but I wonder why evince is slower than gpdf and it doesn't render graphics antialiased. With the cairo backend I'm afraid that evince's performance is even slower. Sorry guys, I really appreciate your work (and no doubt evince rocks), but I guess that AMD Athlon XP-M 2400+ and 512MB RAM should be enough to run evince (as they are to run gpdf).
GPdf doesn't render the whole page to a pixbuf like evince. It uses gnome-canvas (indirectly). That makes zooming very fast and allows almost arbitrary zoom levels. One of the very few advantages of GPdf's codebase.
Thanks, Martin, for you reply. My question is now: wouldn't it be possible that evince rendered the page the same way that GPdf does?
One of the new features of xpdf-3.01 is the following: At high zoom levels, don't rasterize the entire page - this avoids problems running out of memory. Couldn't this be added to evince so that zooming will be faster? (If this should be reported to poppler developers, please tell me.)
*** Bug 321138 has been marked as a duplicate of this bug. ***
Raising priority due to: This bug has been opened here: http://bugzilla.ubuntu.com/show_bug.cgi?id=18496 "Evince starts with wild swapping and finally crashed on my machine when Zooming the attached PDF-File to 400%. http://bugzilla.ubuntu.com/attachment.cgi?id=4787 A sample PDF-File ... > Thanks for your bug. Does it crash or is ejected because it uses too much ressources? Do you get a bug-buddy dialog when that happens? ... I did not get a bug-buddy report. So it probably consumed to many resources. The computer has 512 MByte Ram + the same SWAP Ram. So such a resource consumption seems to be more or less a bug and not a feature ;-) Furthermore, XPDF has no problems with presenting the file at 400%."
I read somewhere (and I wrote in a poppler bug, but I don't remember which one), that the lastest release of xpdf 3.01 includes: At high zoom levels, don't rasterize the entire page - this avoids problems running out of memory. Poopler developers are merging the xpdf-3.01 code into poppler, but I'm not sure they will include this particular feature.
poppler does support only partial rendering of the page (I was told on poppler mailing list). I guess that it would be very useful to improve partial page rendering for the actual part of the page that evince displays. This would make evince faster and this is important.
*** Bug 343328 has been marked as a duplicate of this bug. ***
Since poppler does support partial rendering of a page (on both splash and cairo backends, I guess) and the main problem with the zooming feature in evince is that its backend has to render the whole page, why doesn't evince implement the partial rendering that poppler offers?
Just because nobody is working on it :( It's possible to render page partially, but you should take into account EvPixbufCache, it allows quite fast drawing and can't be dropped as well. Currenly EvPixbufCache is page-oriented and that is the main problem in using partial-page rendering.
Updating version fields.
http://metro.net/riding_metro/riders_guide/system_map.pdf Another PDF that kills my 768MB + 1GB swap system. Zooming to 400% immediately fills up swap and then churns on my system. I didn't leave it running long enough to finish. Another bad thing is that once you set evince to 400%, it will always open that file at that zoom level, effectively making evince unusable with that file.
*** Bug 499810 has been marked as a duplicate of this bug. ***
Apologies for logging a dupe of this bug - I did have a nose around but failed to find this one. Just to add my very small voice, I'd be perfectly happy to have higher zoom levels available with a naive implementation at the risk of the program dying. As it is, certain documents are of no use to me at all in evince. Perhaps for ease of implementation a simple(ish) hack would be to add higher zoom levels to the menu with a warning dialog on selecting them and a test on the preference-saving part to ensure that nothing higher than 400% is saved for a doc? I realise that this suggestion is hideous :-)
*** Bug 507650 has been marked as a duplicate of this bug. ***
I've been following this "bug" for a while. Does anyone know the status of the request? Is there any chance of getting a > 400% zoom level?
This bug depends on a refactoring of the Evince rendering code to render only parts of pages (poppler couldn't do this before, but can now, afaik). It's quite hard to fix, but the OLPC people have recently shown some interest in this issue as well, so there's hope ;)
Well this feature is the ONLY reason I keep acroread around ;)
(In reply to comment #23) > Well this feature is the ONLY reason I keep acroread around ;) You forget the annotations :)
Iget same issue with big djvu files. For example: "Pennsylvania County Type 10 Maps in DJVU Format" http://www.dot.state.pa.us/Internet/Bureaus/pdPlanRes.nsf/infoBPRCountyType10MapsDJVU?OpenForm&AutoFramed djvudump franklin_GHSN.djvu FORM:DJVU [720740] INFO [10] DjVu 13200x18600, v25, 300 dpi, gamma=2,2 CIDa [36] Sjbz [621454] JB2 bilevel data FGbz [6340] JB2 colors data BG44 [23602] IW4 data #1, 72 slices, v1.2 (color), 4400x6200 BG44 [11380] IW4 data #2, 11 slices BG44 [19832] IW4 data #3, 10 slices BG44 [38018] IW4 data #4, 10 slices This file will crash with zoom 200 % on my system with 2GB RAM and 2GB SWAP
Here's another file that kills my system: http://www.cmap.polytechnique.fr/~mallat/papiers/MallatTheory89.pdf Evince uses more than 600MB for this 2.8MB file after paging through it. This is one of three bugs in my Ubuntu system that makes the system (nearly) unusable.
Yes, it would be nice to be able to zoom more than 400% for conference posters. Thanks!
It isn't just an issue of being able to increase precision when reading pdfs, it also is an issue of being able to read the pdf in the first place. Not everyone believes that pdfs should be analogous to printed paper, eg: http://olex.openlogic.com/wazi/2008/license-comparison-matrix-pdf_screenshots/ Hopefully some intrepid soul will help with the refactoring.
I would really love to have greater zoom levels too. Even if when rendering the full page it is a problem, surely there should be some option to set the maximum zoom so that people who have more powerful machines can take advantage of them. Additionally, I have a situation where a priority program by default renders their pdfs 1 in by 1 in and you need to zoom in by more than 400% to get a good look. I am sure in this situation that zooming to more than 400% would place much burden on the system. So maybe maximum level should be pdf page size (and complexity??) dependent.
Hello there, I am sorry to say that, but ... Hey! Evince developers! Wake up! This issue has not been solved for five years! Come on, guys! Everyone wants to zoooooom :) No kidding! This has to be resolved now!
Yeah, we know, but there are good reasons why this hasen't been fixed yet. The best way to fix this would be implementing tile based rendering, but poppler is designed to parse and render, so that rendering every slice takes almost the same time than render the whole page. We would need to change poppler to parse to intermediate format and then render which is not trivial.
(In reply to comment #31) > The best way to fix this would be implementing tile based rendering, but > poppler is designed to parse and render, so that rendering every slice takes > almost the same time than render the whole page. We would need to change > poppler to parse to intermediate format and then render which is not trivial. So this bug should be reported to Poppler?
(In reply to comment #32) > So this bug should be reported to Poppler? Yes. As soon as Evince developers are not able to work it out, I do not see any other possibility. But guys, this should be done five years ago!
see https://bugs.launchpad.net/evince/+bug/241604 for example patch
@Peter: many thanks for your interest and enthusiasm with this issue. @Benjamín: this is not a poppler issue, but it affects evince, more accurately, the way that evince uses poppler to display PDF files. @Pander: this is actually not a patch, but it doesn't solve the underlying problem. This issue is one of the main issues to solve for the next release (http://live.gnome.org/Evince/Roadmap), I mean, last time I checked the roadmap it was. On May, 5th, it had been delayed for a later release. AFAIK, the issue is related to the way evince renders the page. Right now, due to the implementation, evince has to render the whole page, no matter how much of it is displayed. Evince needs a new drawing model that allows partial rendering. This is required for higher zooming levels. And it doesn't seem to be an easy task (I don't code myself). About the issue itself and to the Evince developers: many thanks for your excellent work on Evince. The issue is important for both general speed improvements and needed higher zooming levels. This issue was planned for versions 2.32, 2.30, 2.28, 2.26, 2.24 and it was delayed for later releases. So that users know what is to be expected from this issue, an statement from developers would be extremely helpful. I wonder whether the issue has been assigned already (it is not clear to me whether a primary contact is an assigned developer). Considering that this issue has been marked as critical with high priority, I don't understand why it has been delayed again. I don't really understand why new features are implemented (which is great, no doubt) while this basic functionality is still waiting for a fix. I don't want to start a flame at all. I have some questions on this issue that is already 5 years old (as Peter noticed). An explanation would help to understand things. The interrogation that comes to my mind is the following: do you really think that adding multimedia capabilities to a document reader is more important than enabling partial rendering? Again, I don't want to start any flame, not even a discussion. I'd really appreciate a kind of “official” statement that addresses these questions. Congratulations for your excellent work and many thanks for your help, Pablo
(In reply to comment #35) > @Benjamín: this is not a poppler issue, but it affects evince, more accurately, > the way that evince uses poppler to display PDF files. actually both, it could be fixed in evince, but due to poppler design it would make evince very very slow. > @Pander: this is actually not a patch, but it doesn't solve the underlying > problem. indeed. > This issue is one of the main issues to solve for the next release > (http://live.gnome.org/Evince/Roadmap), I mean, last time I checked the roadmap > it was. On May, 5th, it had been delayed for a later release. I removed it from the Reoadmap for 3.0 when I realized that with current poppler tile rendering would make evince very slow. > AFAIK, the issue is related to the way evince renders the page. Not exactly, all rendering is done by poppler, not by evince. > Right now, due > to the implementation, evince has to render the whole page, no matter how much > of it is displayed. Evince needs a new drawing model that allows partial > rendering. This is required for higher zooming levels. And it doesn't seem to > be an easy task (I don't code myself). Exactly, the idea was to implement tile based rendering, so that instead of asking poppler to render the whole page, we ask to render slices of the page depending on the current view area. That requires to re-work the current pixbuf-cache, since it's based on pages rather than slices (or tiles) > I wonder whether the issue has been assigned already (it is not clear to me > whether a primary contact is an assigned developer). Yes, José Aliste is/was working on it. > Considering that this > issue has been marked as critical with high priority, I don't understand why it > has been delayed again. I don't really understand why new features are > implemented (which is great, no doubt) while this basic functionality is still > waiting for a fix. Because we need to fix poppler first, and it's not an easy task since it's actually a design issue. Current poppler API allows to render a random slice of page, but due to poppler design, rendering a slice takes mostly the same time than render the whole page, only if we need two slices, rendering the page would be 2x slower. Every time you ask poppler to render a slice, it needs to parse the whole page and then the slice is drawn. Most of the time when rendering is spent parsing the page, not drawing. We need to change poppler to use an intermediate format that can be used to render the page. > I don't want to start a flame at all. I have some questions on this issue that > is already 5 years old (as Peter noticed). An explanation would help to > understand things. The interrogation that comes to my mind is the following: do > you really think that adding multimedia capabilities to a document reader is > more important than enabling partial rendering? No, it's not more important, just more realistic. > Again, I don't want to start any flame, not even a discussion. I'd really > appreciate a kind of “official” statement that addresses these questions. I know, you feedback is very appreciated.
Thanks to all for the feedback. My notes indeed do not fix the underlying problem. However, I'm able to zoom as I please even though it costs me lots of CPU power and I can live with that for now. I hope this initiates fixing of poppler. Meanwhile, allowing for zooming up to e.g. 1600% (a scaling of 8) would please many users without getting into too much CPU load. Would evince maintainers like to consider this for now?
(In reply to comment #36) > (In reply to comment #35) > > [...] > > Right now, due to the implementation, evince has to render the whole page, > > no matter how much of it is displayed. Evince needs a new drawing model > > that allows partial rendering. This is required for higher zooming levels. > > And it doesn't seem to be an easy task (I don't code myself). > > Exactly, the idea was to implement tile based rendering, so that instead of > asking poppler to render the whole page, we ask to render slices of the page > depending on the current view area. That requires to re-work the current > pixbuf-cache, since it's based on pages rather than slices (or tiles) Thanks for your reply, Carlos. Would it take long to rewrite the pixbuf-cache? > > I wonder whether the issue has been assigned already (it is not clear to me > > whether a primary contact is an assigned developer). > > Yes, José Aliste is/was working on it. On evince, poppler or both? > > [..] > > I don't really understand why new features are implemented (which is great, > > no doubt) while this basic functionality is still waiting for a fix. > > Because we need to fix poppler first, and it's not an easy task since it's > actually a design issue. Current poppler API allows to render a random slice > of page, but due to poppler design, rendering a slice takes mostly the same > time than render the whole page, only if we need two slices, rendering the > page would be 2x slower. Every time you ask poppler to render a slice, it > needs to parse the whole page and then the slice is drawn. Most of the time > when rendering is spent parsing the page, not drawing. We need to change > poppler to use an intermediate format that can be used to render the page. Thanks for your explanation. I guess this improvement won't be planned for the next 0.14 release, but for version 0.16, which could be release six months from the 0.14 release (early 2011). Is there any poppler bug report where those ones interested could follow the issue? (If such report exists, I wonder whether it would be possible to mark that this issue depends on that poppler bug.) > > [...] > > The interrogation that comes to my mind is the following: do you really > > think that adding multimedia capabilities to a document reader is more > > important than enabling partial rendering? > > No, it's not more important, just more realistic. I agree. Having some info from the poppler side would be extremely useful. Thanks for your help, Pablo
(In reply to comment #38) > Would it take long to rewrite the pixbuf-cache? Well, I think it could be done in a release cycle. > > Yes, José Aliste is/was working on it. > > On evince, poppler or both? on evince > I guess this improvement won't be planned for the next 0.14 release, but for > version 0.16, which could be release six months from the 0.14 release (early > 2011). I has been never planned actually. > Is there any poppler bug report where those ones interested could follow the > issue? (If such report exists, I wonder whether it would be possible to mark > that this issue depends on that poppler bug.) No, there isn't any bug report.
I've just pushed a patch to git master to use a dynamic cache size to increase the zooming level. See http://git.gnome.org/browse/evince/commit/?id=d375c36972ff3a01b7979984b5a1043eb4c807b0 please, try it out and let me know whether it works for you. Thanks.
(In reply to comment #40) > I've just pushed a patch to git master to use a dynamic cache size to increase > the zooming level. See > > http://git.gnome.org/browse/evince/commit/?id=d375c36972ff3a01b7979984b5a1043eb4c807b0 > > please, try it out and let me know whether it works for you. Many thanks, Carlos. May I ask whether this is a workaround for a faster partial rendering from poppler? Thanks again, Pablo
No, it's not a workaround, this just changes the way the pixbuf cache works, but it still renders the whole page. Pixbuf cache cached always 2 pages before and after the current page range, no matter what the zoom level was. However, for lower zoom levels the memory required for every page is less, so we can cache more pages in this case without increasing the memory required. In the same way, when the zoom level is high we can just save memory by not caching any pages at all and use that memory to be able to render pages at a higher zoom level. This means there's still a limit, but it depends on the memory used rather than a static number of pages. With tile based rendering we could zoom in/out limitlessly
Carlos, I wonder whether the release of cairo-1.10 might help to tile based rendering. Thanks for your help, Pablo
Pablo, the new child surfaces in cairo-1.10 coul help to make the refactoring of the pixbuf cache a lot simpler, although I need to investigate about memory usage when only some sub-surfaces of a bigger surface have data. However, we will still need the poppler refactoring to avoid reparsing everytime a render is made.
(In reply to comment #43) > Carlos, > > I wonder whether the release of cairo-1.10 might help to tile based rendering. It might help, but main problem is still the poppler parsing and rendering model. > Thanks for your help, > > > Pablo
(In reply to comment #44) > Pablo, the new child surfaces in cairo-1.10 could help to make the refactoring > of the pixbuf cache a lot simpler, although I need to investigate about memory > usage when only some sub-surfaces of a bigger surface have data. However, we > will still need the poppler refactoring to avoid reparsing everytime a render > is made. Thanks for your replies, José and Carlos. I guest that both evince and poppler should be improved, so rendering would be as fast as it is possible. BTW, José, do you plan to work on parsing and rendering in poppler? Thanks for your help, Pablo
*** Bug 632857 has been marked as a duplicate of this bug. ***
I've ended up filing a related bug: "Evince restricts maximum zoom to 70% on large (area) documents" http://launchpad.net/bugs/721217 Should I move that upstream as a new bug-report, or as the intended fix for this bug (maximum zoom arbitrarily limited to 400%) been the cause of this one?
Paul, this is intentional, we restrict the amount of memory that evince will use, so for big documents you don't get many options on the zoom level. The current limit is around 100 MB I think and it is hardcoded in the code. Of course we could make it configurable by a gsetting key, but the real thing is to fix the cache code to only cache visible regions instead of the hole page...
Why not do both? GIMP also allows users changing limits for maximum memory usage.
José: thanks for the answer, filed separately as: "Hardcoded cache size limit restricts maximum zoom to 70% on large (area) documents" https://bugzilla.gnome.org/show_bug.cgi?id=642683
Still waiting impatiently for this bug to be fixed.
weird. I don't know why I haven't commented on this. I am working on a solution... I have a working solution for non-dual-mode that allows tile rendering, and thus, allow evince to use less memory on higher zoom. Unfortunately, I am on leave until march, and in march I have three courses to teach, so it is safer to assume that I might finish this around the 3.8 release, which means that it won't be merged before the 3.10 release.
I have just read that there is GSOC project by Aakash Goenka (mentored by José) on this bug. I wonder whether the project also includes fixing the poppler side of the issue (according to comment 31 by Carlos).
Pablo, the poppler side is much more difficult to solve and I don't think we will have time to taclke it within this SoC. Otherwise, the slowness should not affect how things work in evince because we'll use tiles that are big enough so we don't need many tiles each time...In fact, most probably we 'll use tiles only for large zoom modes where a page would make several screens wide.
*** Bug 724252 has been marked as a duplicate of this bug. ***
Is this going to be merged soon?
David: Doesn't merging require a patch first?
Andre sorry I thought a patch had already been submitted, I remember the GSOC user having a local git branch last time I checked on this bug
*** Bug 752885 has been marked as a duplicate of this bug. ***
Thanks for working on a patch for this @Jose! Together with the great recently added annotation features, increased max zoom level would make me able to completely move away from wine and PDF-XChange. Especially when reading scientific papers and similar articles where there are many figures in total, I find myself not being able to go further than ~ 250% which is not enough to see the small details in the figures.
What is the current status about that bug? I read about a merge. But in Debian unstable the limit is still at 400%.
(In reply to c.buhtz from comment #65) > I read about a merge. Then please provide links to the place where you read that. > But in Debian unstable the limit is still at 400%. Then please provide info which Evince version is in "Debian unstable".
https://tracker.debian.org/pkg/evince
@c.buhtz: And that link shows "a merge" where exactly?
Currently it is 3.22.1-4. You can check here https://packages.debian.org/source/unstable/evince
@c.buhtz: Would you please answer my first question in comment 66 by providing an exact link and a quote so I know which phrase to search for? Thanks!
I don't have a link or source. When I would I had reported it here. Sorry.
So the last six comments cover discussing random unsourced rumors. Alright...
*** Bug 788909 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/6.