Remove rendering wait image from page changes

Bug #1424738 reported by Richard Lewis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
qpdfview
Opinion
Undecided
Unassigned

Bug Description

When I change to a new page a graphic indicative of a timer appears, presumably while the page is being rendered, before the page itself is displayed. When in presentation mode this is not very pleasing; it normally appears very briefly and so actually results in unpleasant flashing at page changes. It would be much more preferable to display the current page while the next page is being rendered, and then display the next page when it is ready.

One workaround is to enable 'prefetch' in the Graphics | General settings. However that fails when moving quickly through the pages if the prefetch count is low. It also doesn't help at all when moving backwards through the pages.

Revision history for this message
Richard Lewis (ironchicken) wrote :

I should have reviewed this more carefully before I submitted. This doesn't exactly ready like a bug report in that I should have reported the problem rather than my own idea for a solution. So please consider only the problem of flashing page changes, rather than the specific suggestion of removing the rendering wait image. All viable solutions should, of course, be considered.

Revision history for this message
Adam Reichold (adamreichold) wrote :

Hello Richard,

I agree that the progress and errors icons might not be ideal for the presentation mode. However, displaying the current page is probably rather complicated since the "view" does not know what is displayed by the "items" or whether the rendering is actually complete. This is intentional as it encapsulates the rendering from the layout functions. A simpler change could be to just not display those placeholder icons, but it would still "flash" to a blank page in between page changes.

Holding the current page is possible in principle but I think it will become quite complicated also from a usuability POV as it suggests the need for another feedback mechanism for a page change, e.g. when skipping multiple pages one by one there would be no apparent effect until the final page would actually be rendered which can take some time due to asynchronuous rendering and canellation issues.

Another option entirely could be to synchronuously render a low-resoultion version of the page which is the first thing that is displayed until the final version is available. But that will again yield a two-step page change.

But IMHO prefetching is the preferred way of resolving this as it coveres the most common case for a presentation using minimal effort. Also concerning backwards prefetching: If one increases the prefetch distance to at least two, it should also prefetch backwards, i.e. if the prefetch distance is d, the next d and the previous d/2 pages are prefetched if the cache is sufficiently large.

Best regards, Adam.

Revision history for this message
Adam Reichold (adamreichold) wrote :

Marking this as a statement of opinion as there was no further discussion and the currently preferred solution is to set up prefetching.

Changed in qpdfview:
status: New → Opinion
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.