| Summary: | [Wayland] Panning in Okular is laggy with 4K monitor | ||
|---|---|---|---|
| Product: | [Applications] okular | Reporter: | Simone <s.scalabrino9> |
| Component: | general | Assignee: | Okular developers <okular-devel> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | aacid, j.filzmaier, nate, nikolakocicbz, oliver.sander, postix, xgreenlandforwyy |
| Priority: | NOR | ||
| Version First Reported In: | 21.04.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=387567 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Simone
2019-07-09 09:10:12 UTC
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 > 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? |