qpdfview

Improving zoom in/out

Asked by Arnaud Schmittbuhl

When I "ctrl+mouse wheel up or down" to zoom in or out, different things happen:
- the current page disappears
- a clock appears in the upper left corner of the page
- after a small delay, the zoomed page reappears

So, during a fraction of time, I am looking at a white page.

Is there any possibility to avoid this blank page? It's really annoying when you zoom in graphics. Graphics on / zoom in / graphics off /
graphics on / zoom in again / graphics off / graphics on...
Maybe by forgetting about the clock and let the unzoomed page keep in place?

xpdf (poppler based too) is faster to zoom in/out... why?

Thx again

Question information

Language:
English Edit question
Status:
Solved
For:
qpdfview Edit question
Assignee:
No assignee Edit question
Solved by:
Arnaud Schmittbuhl
Solved:
Last query:
Last reply:
Revision history for this message
Adam Reichold (adamreichold) said : 		#1

Hello Arnaud,

I think that there are two points to make here:

* Concerning the comparison with xpdf (On which AFAIK Poppler is originally based, not the other way around?), I think it does rendering synchronously, i.e. blocking the interface while doing it, so while it will compute a single state change faster, the responsiveness of the interface is generally worse.

* The reason for the progress icon being displayed is that the graphics state (e.g. bounding rectangle and so on) is updated, but rendering is only initiated in a background thread, with the result being displayed as soon as it is available. We used to have an build-time option to disable background rendering, but it really makes the interface harder to use.
One useful way of going about this is to scale up the already rendered image up to the new size until the higher-resolution rendering is finished (this is for example done in Okular). But while this is a nice feature, I have never felt the urge to implement it since the activity is indicated by the progress icon without introducing another state to the rendering process and further delaying the freeing of the buffer containing the obsolete image.

In short, at the moment, I don't really see the necessity to implement this and thereby complicating the rendering process.

Best regards, Adam.

Revision history for this message
Arnaud Schmittbuhl (aschmittbuhl) said : 		#2

OK, thanks for answers.

Arnaud

Revision history for this message
Adam Reichold (adamreichold) said : 		#3

Hello again,

Since this isn't the first time we discussed and after thinking about it a bit, a possible implementation seems much simpler than I expected it to be, I added a wishlist bug to include this in version 0.4.6, c.f. the linked bug report. There is also a branch lp:~adamreichold/qpdfview/obsolete-pixmaps available (also linked in the bug report) which implements this. It currently misses the setting which will be necessary since this can increase memory usage and will hence be disabled by default.

If you feel comfortable with building from source and would like to help with this feature, please try out the branch and report your findings in the bug report.

Best regards, Adam.