Bug 426504 - While inertially scrolling through a multi-page file, not-previously-seen pages are not rendered until scrolling ends
Summary: While inertially scrolling through a multi-page file, not-previously-seen pag...
Status: CONFIRMED
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 1.11.0
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-13 23:55 UTC by Brendon Higgins
Modified: 2020-09-14 23:02 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brendon Higgins 2020-09-13 23:55:01 UTC
SUMMARY

New pages that come into view, which have not previously been rendedered, are not rendered while inertially-scrolling through a multi-page file. They are only rendered once the scrolling animation stops.

STEPS TO REPRODUCE
1. Open a multi-page file (I've tested PDF and CHM files).
2. Grab the page and fling it once so that Okular starts inertially scrolling through the pages at decent speed.
3. Watch the pages come into view.

OBSERVED RESULT

After the first couple of pages (maybe related to a performance setting?) subsequent pages are all unrendered (blank, except for the Okular icon in the top left corner of the page). It doesn't seem to be related to the complexity of the pages, and continues even as the scrolling animation slows down. As soon as the inertial scrolling stops or the user grabs the page, the page(s) in view are rendered. The renderer seems to be waiting for the scrolling to stop.

EXPECTED RESULT

Pages are rendered as/before they come into view.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.70.0
Qt Version: 5.14.2

ADDITIONAL INFORMATION

With this bug, inertial scrolling is not useful for scanning through a document (otherwise it might be a good use-case; e.g. looking for a half-remembered figure). I haven't seen this behaviour with any of the regular scrolling methods. PgUp/PgDown may just move too slowly to show the effect (especially with #422050, but perhaps now that's fixed...), even though it uses animation.

No-one else noticed this? Or maybe something is messed up in my config? Honestly not sure - sorry for the noise, if it's just me.