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.
