[okular] [Bug 460681] New: Laggy scrolling on high DPI display - profiling indicates excessive copying in PagePainter::paintCroppedPageOnPainter
https://bugs.kde.org/show_bug.cgi?id=460681 Bug ID: 460681 Summary: Laggy scrolling on high DPI display - profiling indicates excessive copying in PagePainter::paintCroppedPageOnPainter Classification: Applications Product: okular Version: unspecified Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: maximumsometh...@gmail.com Target Milestone: --- SUMMARY On my computer - a laptop with a 4k display set to 250% scaling - Okular scrolls through PDFs at ~30 FPS and consumes 100% CPU while doing so. I did some profiling, and the main thread was spending 80% of its time on PagePainter::paintCroppedPageOnPainter. Looking at the source code, it's doing a few things very inefficiently: (1) It asks the input page for a QPixmap, then dereferences it and calls QPixmap::setDevicePixelRatio, which creates a deep copy of the pixmap; (2) Whenever it wants to draw a cropped scaled rectangle of the pixmap, it first creates a scaled copy of the pixmap then draws it rather than drawing it directly. (1) is specifically related to having a non-1 scale factor, while (2) is I suspect just exacerbated by the high pixel count of the display. I was going to go ahead and fix these things myself, but I was wondering if anyone familiar with the code knows why it was written this way/any gotchas that might apply if the deep copies are not made. STEPS TO REPRODUCE 1. Open any PDF on a display with a high scale factor. 2. Scroll around. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.4 Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 460681] Laggy scrolling on high DPI display - profiling indicates excessive copying in PagePainter::paintCroppedPageOnPainter
https://bugs.kde.org/show_bug.cgi?id=460681 --- Comment #2 from maximumsomething --- It would fix the biggest problem, yes. However, it turns out setting the dpr of the source pixmap isn't necessary at all. I went ahead and made a merge request that addresses both problems. See https://invent.kde.org/graphics/okular/-/merge_requests/665 . -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 423360] Viewport blinks (flashes, disappears) while scrolling or dragging at moderate or high zoom levels
https://bugs.kde.org/show_bug.cgi?id=423360 maximumsomething changed: What|Removed |Added CC||maximumsometh...@gmail.com --- Comment #7 from maximumsomething --- Can confirm this is still an issue on the latest git master, 22.11.70. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 423360] Viewport blinks (flashes, disappears) while scrolling or dragging at moderate or high zoom levels
https://bugs.kde.org/show_bug.cgi?id=423360 --- Comment #8 from maximumsomething --- 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. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 496282] New: GTK apps that try to inhibit logout inhibit sleep instead under Wayland
https://bugs.kde.org/show_bug.cgi?id=496282 Bug ID: 496282 Summary: GTK apps that try to inhibit logout inhibit sleep instead under Wayland Classification: Plasma Product: Powerdevil Version: 5.27.11 Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: maximumsometh...@gmail.com CC: natalie_clar...@yahoo.de Target Milestone: --- SUMMARY Both gnome-text-editor (GTK4) and gedit (GTK3) will inhibit sleep when run under KDE. Both use straightforward GTK apis to inhibit logout when there are unsaved documents. But in KDE, the "battery and brightness" widget will show them as inhibiting sleep, and the machine will indeed not go to sleep automatically. Sleep is not inhibited under GNOME Wayland or Plasma X11, just Plasma Wayland. (Logout is also not successfully inhibited, as documented in https://bugs.kde.org/show_bug.cgi?id=461176). Given that this issue is specific to KDE under Wayland, I am filing it with KDE instead of GTK I think the actual bug is more likely to be here. STEPS TO REPRODUCE In a KDE wayland session, open gedit, gnome-text-editor, or any other GTK app that inhibits logout. Observe that sleep is inhibited in the "Battery and Brightness" taskbar widget and the computer does not go to sleep automatically. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 12 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 Kernel Version: 6.11.4-amd64 (64-bit) Graphics Platform: offscreen Processors: 16 × AMD Ryzen 9 5900HX with Radeon Graphics Memory: 30.8 GiB of RAM Graphics Processor: AMD Radeon Graphics -- You are receiving this mail because: You are watching all bug changes.
