Okular version: 19.04.2 SUMMARY Using a 4K external display with my laptop in Wayland makes the "Browse tool" very laggy. For example, if I press the left mouse button, I move the pointer and I release the button, the viewing area of the PDF moves, but 4/5 times more slowly than the mouse pointer, i.e., it keeps moving when I release the button. If I do the same in the "Thumbnails" area, instead, it works correctly. I think this is similar to https://bugs.kde.org/show_bug.cgi?id=387567. I can experience the problem when: 1) the "Browse tool" is used in the PDF area; 2) the scrollbar of the PDF area is moved. Okular works correctly when: 1) I browse the thumbnails of the PDF; 2) I use the mouse wheel. STEPS TO REPRODUCE 1. Open a PDF Okular with a 4K external monitor connected 2. Press the left button in the PDF view area, move the pointer, release the button OBSERVED RESULT The movement is significantly slower than the pointer, the viewport keeps moving even after the mouse button is released. EXPECTED RESULT The viewport moves as fast as the mouse pointer and it stops when the left button is released. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.1.15-arch1 (available in About System) KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.13.0 Monitors: dual monitor, one 4K (external, scaled 2x), one 1080p (integrated in the laptop, not scaled) VGA controller: Intel Corporation UHD Graphics 630 ADDITIONAL INFORMATION This happens only in Wayland, not in X11. If I remember correctly, it doesn't happen when I don't connect the external monitor.
I can reproduce this issue on my lenovo thinkpad x1 carbon gen9. I do have a 4k screen and scrolling pages within this document is almost unusably slow. Opening the PDF in Firefox (wayland enabled) has way better performance. This Problem is *not* dependent on a secondary screen being plugged in (at least in my case) Operating System: Arch Linux KDE Plasma Version: 5.22.3 KDE Frameworks Version: 5.83.0 Qt Version: 5.15.2 Kernel Version: 5.12.15-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 8 × 11th Gen Intel® Core™ i7-1185G7 @ 3.00GHz Memory: 31,1 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics
Can reproduce.
Does it happen only with PDF? Or only if there is e. g. a stamp annotation? Or do you use the Change Colors feature? Have some text selections active? Which Okular version do you use? Simone reported this for 19.04.2, but there was a recent change related to screen scaling, which possibly affects performance.
It does not seem to be dependent on the file format / generator. I have tested with pdf, txt and epub, and tiff - all have laggy scrolling. I am using Okular 21.04.3 but can also reproduce it with the current master branch. I have built okular from source, if you can point me at interesting source files to debug i am glad to help. The Effect is especially extreme if i unplug the device (e.g. when TLP enables some power saving features like power_save cpu_governor etc) so it does seem like a performance regression
Thanks. The most relevant source is probably part/pageview.cpp and part/pagepainter.cpp. PageView::paint() might (indirectly) tell Wayland wrong stuff so it does more than necessary. PagePainter paints the document (this is usually the only painting done in PageView::paint()), and has a fast and a slow code path. Maybe the fast path doesn’t work on your system. The repository is at https://invent.kde.org/graphics/okular.
Do you also see the problem without scaling? Screen scaling works differently under Wayland, and you may[0] end up with an 8K temporary bitmap. That is simply a lot of data, and maybe the lagging is for that? [0] I am not 100% about this, but it is worth checking.
@Oliver Sander I can confirm that the problem is related to display scaling. If i change the display scale to 100% the performance is as expected, even if the resolution is at 4k and the cpu_governor is set to "powersave". Today i have some spare time, so i will now try to debug this issue and report my findings
I couldn't yet find a solution to the probelm, a few questions though: https://invent.kde.org/graphics/okular/-/blob/master/core/document.cpp#L1519 Why is devicePixelRatio here forced to be 1 instead of QScreen::devicePixelRatio()? If enabling PAGEVIEW_DEBUG=true the build fails because kWarning does not exist on my machine. If this is a bug i could create a merge request that fixes this. Is there a way to tell an application to use the scale of 225%, as configured within the "Display and Monitor" KCM? QT_SCALE_FACTOR does not seem to have the same effect. ---- When starting Okular it reports in the 225% Display Scale case: org.kde.okular.core: sending request observer=0x560658c0b5d0 3582x5001@1 async == true isTile == false When starting in 100% Display Scale case: org.kde.okular.core: sending request observer=0x5585941d7490 2688x3751@2 async == true isTile == false My suspicion is that the difference in requestRect size causes a problem here. I'm still investigating how this size comes to be On another note: Typing in values in the "Display and Monitor" KCM's "Scale" Spinner directly is a really weird experience
Those kWarnings need to be changed to qWarning
Created a MR: https://invent.kde.org/graphics/okular/-/merge_requests/458
> Why is devicePixelRatio here forced to be 1...? That part of the code was reworked in a recent merge request. Maybe it'll help you: https://invent.kde.org/graphics/okular/-/merge_requests/371
Confirm that this issue still exists on my Debian 12 Plasma-5.27 laptop. Is there any progress these days?