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

[Henrik Fehlauer]

rkflx added a comment.


  The latest version is much better and I could not reproduce my issues from above anymore. Still some oddities (tested using `dublin-center-street.pdf`):
  
  - With Fit Page, first the main view renders and after finishing the thumbnail should be the only thing left to render. However, the thumbnail takes a much longer time to show an initial frame with the CPU being busy throughout doing something else (after this, the incremental rendering seems to need about the same time as the main view). It is likely this has been there all the time and the patch just makes this phenomenon more visible, nevertheless may be a candidate for huge CPU time savings in a later patch (freeing resources for subsequent pages).
  - When zooming, the initial timeout to start showing the incremental rendering seems much longer than 500ms and also much longer compared to when reloading the document at the same zoom level afterwards. Okular seems busy doing something else. Maybe the rendering of intermediate zoom levels is not cancelled correctly? This is also seen when closing Okular with rendering still in progress, where the shell prompt returns only much later while the window closes immediately.
  - In some situations, incremental rendering happens twice in a row, i.e. the first pass is thrown away when finished and a second pass starts. (Occurs now and then, unfortunately I cannot give you instructions on how to reproduce yet. Try moving around with the scroll wheel when zoomed in.)
  - Segfaults on entering Presentation mode (works fine without the patch to Okular but still with the newer Poppler).
  - Extensive flickering of some screen areas (switching between white and content rapidly for several seconds) when redrawing after panning a rotated page in some cases, even a segfault occasionally.
  
  Not sure whether all of this should even be fixed in this patch, but I would appreciate a short comment from you regarding those points.
  
  > I don't see a need to limit it really (other than the initial 500ms barrier)
  
  Just to put some numbers behind this: A quick measurement with a stopwatch and an artificially slowed down CPU consistently gives me total rendering times of ~7.5s vs. ~9.0s, i.e. the patch is ~15% slower.
  
  > lots of pages take more than 30ms and you don't really want to see them rendering just twice
  
  I tried to get a feeling for the difference between updating immediately (which I presume would be more pleasant) and updating after a delay of much more than the typical 30ms human perception normally does not notice (which you claim to be preferable). However, there are so many timeouts/delays and intermediate images like the scaled up thumbnails happening, that to even compare both approaches a substantial code rework would be needed. Let's just keep it as proposed, then.

REPOSITORY
  R223 Okular

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

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