Created attachment 129583 [details] Viewport flashing while scrolling with Trackpoint SUMMARY When I zoom far enough that not the whole page is visible at once, the viewport repeatedly disappears briefly while dragging. STEPS TO REPRODUCE 1. Zoom to a detail 2. Drag or scroll using a continuous scrolling device OBSERVED RESULT The page contents disappear briefly, see screencast EXPECTED RESULT Page is always shown, at least where it is already rendered SOFTWARE/OS VERSIONS KDE Neon 5.19 KDE Plasma Version: 5.19.1 KDE Frameworks Version: 5.71 Qt Version: 5.14.2 ADDITIONAL INFORMATION Recently I noticed this bug, and I *think* it appeared only recently. IIRC it looked better after compiling from v19.12.3. Unfortunately I couldn’t figure out how to install an older version today.
> Page is always shown, at least where it is already rendered That's a wrong expectation, at some point we need to evict pages already rendered because otherwise at very high zoom levels we'd just fill all your memory. Now, is this a regression and this should not be happening? Maybe, I'm just writing here to make clear that your expectation is not 100% correct.
I marked all the pixmaps fetched by PagePainter, to understand how tiling works. * A rounded rectangle precisely marks the tile outline. * Two “measuring tapes” show me that the pixmaps are shown in their correct size. * 8 color swatches in the center show a 24 bit hash of the pixmap pointer, so it is easy to see when exactly new pixmaps are created. * A red and a cyan 3px square are placed exactly in the NW and SE corners, so I can exactly see how PagePainter positions the tiles. If the tiles are misaligned, these squares are cut from [] to [ or to | or even disappear. (It is visible that TileManager stores 1px overlapping tiles, at least at 131.25% hiDPI screen scale.) * The exact pixmap size is shown. Code is available at https://invent.kde.org/davidhurka/okular in branch tests_pagepainter-paint-pixmap-tree. This gave me an opportunity to record a detailed video of the flashing viewport. The video is linked below, it’s about 7 minutes long. Well, here is a transcript: 0:00: Small zoom factor, tiling not used. The document is rotated, because then the tiling performance is apparently lower, so the artifacts are easier to record on video. The document is https://20years.kde.org/book/#download . PHASE 1: View without tiling, no flashing. 0:00: Mouse drag, pixmaps stay the same. 0:23: Arrow/Page key scrolling, pixmaps stay the same. 0:36: Selection scrolling, pixmaps stay the same. 0:57: Discrete zooming, resize Thumbnail bar. New pixmaps are generated (only for the PageView document observer). 1:10: Zoom in until tiling is used. 1:15: Trackpoint scrolling. Viewport blinks. PHASE 2: View with tiling, much flashing. 1:30: Reached a page where tiling is always used. Fast and slow scrolling, shows that pixmaps are updated at slow scrolling, and some of them disappear only at fast scrolling. Scrolling with mouse drag and trackpoint. 2:25: Arrow key scrolling. Pixmaps are updated after scrolling stops. 3:23: Page key scrolling. Same behavior as with arrow keys. 4:05: Selection scrolling. Same behavior as with arrow keys. 4:53: Shift + Arrow Up automatic scrolling. Pixmaps are updated irregularily. 5:17: Additional trackpoint scrolling. Similar behavior. PHASE 3: Tile alignment/overlap at 131.25% hiDPI: 5:36: Focus at a tile intersection. The overlap is visible. The red/cyan 3px squares should touch corner-corner, but their corners overlap by 1 or 2 px. You can see the red square alternating between ] and | shape, instead of []. 6:48: Resize Thumbnail bar. PageView tiles disappear. PHASE 4: Rotation: 7:05: Rotate to original orientation. At original orientation the tiles disappear much less frequent. 7:30: Rotating at small zoom factor, no tiling used. Rotating from original orientation rotates the existing pixmaps, rotating to original orientation creates new pixmaps. Conclusions: * It appears that PageView communicates incorrect viewport updates, which confuses the TileManagers. I couldn’t record it in the video, but sometimes it appears that flashes and pixmap updates happen exactly when the viewport in the Thumbnails bar is updated. I suspect that this is a regression from the QScroller patch. More testing is needed with v19.12.3. * Tiles slightly overlap. The issue is that the overlap alternates between 1px and 2px. That is probably caused by rounding errors. It’s not a big issue, and 98% not linked to this bug report. https://cloudstorage.uni-oldenburg.de/s/CKW6nN9kW8oWbg4
(In reply to Albert Astals Cid from comment #1) > > Page is always shown, at least where it is already rendered > > That's a wrong expectation, at some point we need to evict pages already > rendered because otherwise at very high zoom levels we'd just fill all your > memory. > > Now, is this a regression and this should not be happening? Maybe, I'm just > writing here to make clear that your expectation is not 100% correct. Yes, my expectation should read “Page is always shown, at least when the correct pixmaps are right now available in the memory”. Yes, I think this is a regression linked to QScroller, but the issue existed before. But it was much less visible before.
I took some time and made a git bisect for this bug. The result is surprising, because it gives commits from 18.04 already, which means that the problem was not discovered by us for a long time. I think the problem requires a modern Poppler version to appear. Maybe we all used Poppler <0.63? @Oliver: You wrote https://invent.kde.org/graphics/okular/-/merge_requests/134#note_110955 . Do you remember whether you recently updated across Poppler 0.63? This appears to be the first commit which has the problem in unrotated view: > commit 2d8b2c7e95927db1633ecb871ed4100c3e7e3833 > Author: Albert Astals Cid <albert.astals.cid@kdab.com> > Date: Thu Feb 1 19:42:37 2018 +0100 > > Add support for cancellable image rendering and text extraction > > Summary: > Only supported by the pdf backend if using poppler >= 0.63 > [...] > Differential Revision: https://phabricator.kde.org/D9328 For rotated view, the problem existed longer. v16.12.0 is the first which I can compile, and it has this problem.
> @Oliver: You wrote https://invent.kde.org/graphics/okular/-/merge_requests/134#note_110955 . Do you remember whether you recently updated across Poppler 0.63? No, I am quite certain that I had a new poppler when I wrote that.
*** Bug 418994 has been marked as a duplicate of this bug. ***
Can confirm this is still an issue on the latest git master, 22.11.70.
I did some investigating and the problem seems to be that TileManager::setPixmap is being called with a partially rendered (mostly white) pixmap covering the whole screen. Seemingly, whenever a new tile scrolls into view, the entire visible area is re-rendered. While this is happening, Poppler sends several updates with only parts of the PDF processed. The first of these updates is mostly white, and because it covers the whole screen, including tiles that were previously fully rendered, we see flashing. It's easiest to see this happen with a complex PDF that will serve a lot of partial updates. Possible solutions: - Restrict the updated area to only the part of the screen that was not rendered previously. (Possibly the job of DocumentPrivate::sendGeneratorPixmapRequest or Document::requestPixmaps.) - Disable partial renderings. - Never overwrite with a partial render tiles that were previously fully rendered. The first option seems to be the best, but I suspect that there's a reason it was originally written this way.
Is this still an issue now that https://invent.kde.org/graphics/okular/-/merge_requests/665 has been merged?
I just tested it. It has gotten better. It still happens sometimes when scrolling, but not very often. It still does happen quite a lot when zooming in our out though. Fortunately the images are not getting blurry when zooming anymore. There is just white flashing now.