D8379: PDF: Support the new poppler renderToImage with update callback

[Henrik Fehlauer]

rkflx added a comment.


  That's a really great feature Okular's user will surely love. Does this solve https://bugs.kde.org/show_bug.cgi?id=344081?
  
  When testing (with https://phabricator.kde.org/D8378 and https://phabricator.kde.org/D8379 both applied at the same time – sorry for that –, as well as the Poppler patch), there were still some issues for me:
  
  - After zooming in and rendering finished (i.e. CPU usage went back to zero), the display would not update. Only after panning enough so a request for a new tile triggered rendering again the display would also update. (Note: I tested whether this is a regression with the HiDPI commit, but it is not.)
  - Same thing for zooming out.
  - The progressive rendering seems to only work with Fit Page on startup, but not with 100% Zoom on startup or when zooming in later. (My first thought was that there might be some connection to the scaled raster images shown as a temporary preview, but apparently that is not always the case.)
  
  Also I am wondering if the partial updates might slow down the total rendering time, i.e. whether there should be some rate limiting to the partial updates (if there isn't already)?

INLINE COMMENTS

> generator_pdf.cpp:905
> +        // Don't report partial updates for the first 500 ms
> +        timer.setInterval(500);
> +        timer.setSingleShot(true);

Why not set this to something in the region of 30 to 60 fps (e.g. ~30ms instead of 500ms)? This way some overhead would be avoided while potentially still feeling somewhat fluent (i.e. not seeing Okular's loading icon) when scrolling through pages.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D8379

To: aacid, #okular
Cc: rkflx, ngraham, michaelweghorn, mlaurent, #okular, aacid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20171021/0b012654/attachment.html>