| Summary: | Terrible resize performance running in Wayland mode | ||
|---|---|---|---|
| Product: | [Applications] kolourpaint | Reporter: | David G. <david> |
| Component: | general | Assignee: | kolourpaint-support |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | aspotashev, david, haagch.christoph, ojsl, tetyuev.igor |
| Priority: | NOR | ||
| Version First Reported In: | 24.12.3 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
gdb-output
wayland-vs-xcb-demo |
||
|
Description
David G.
2024-11-06 15:58:14 UTC
Can confirm on this Fedora 41 box. Operating System: Fedora Linux 41 KDE Gear 24.08.3 KDE Plasma Version: 6.2.80 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 Kernel Version: 6.11.6-300.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 5600G with Radeon Graphics Memory: 29.2 GiB of RAM FWIW, I just updated KDE Gear from git master and Kolourpaint version 24.11.70 has the same issue. I had this for at least 2 years. I recorded a video today Archlinux with kolourpaint 24.08.3 and mesa 24.2.7 on a Ryzen 3950X and RX 6900 XT. https://www.youtube.com/watch?v=QNVM7jjhktI Be sure to watch the whole 14 minutes for the full experience. I assume in gwenview this is related: Open a large image in gwenview, zoom in, then left click and drag the zoomed in area around. It's better than it was but is still a bit laggy and takes 100% cpu. This issue is still very much making any resize/scale op effectively unusable on Wayland. I added a short screen recording as an attachment to actually show how awful the performance is. I also attached output of gdb (with symbols), which i took while kolourpaint was blocking during the resize. Also during the resize top -H shows only kolourpaints main thread doing any work at ~100% while all the worker and wayland threads are at 0%. The blocking call chain in the gdb output is: kpView::mouseMoveEvent -> kpAbstractSelectionTool::operationResizeScale -> kpToolSelectionResizeScaleCommand::resizeScaleAndMove -> kpAbstractImageSelection::setTransparency -> kpAbstractImageSelection::recalculateTransparencyMaskCache -> QRasterPaintEngine::drawPoints And it happens inside the qt mouse event path: QWidgetWindow::handleMouseEvent -> QWidget::event -> kpView::mouseMoveEvent which is why I initially assumed it was related to mouse polling but: None of these had any effect: - QT_FLUSH_UPDATE=1, QT_FLUSH_PAINT=1 - QT_SCALE_FACTOR=1, QT_ENABLE_HIGHDPI_SCALING=0 - Lowering mouse polling and DPI So now I assume it's not actually input related but related to recalculating the transparencies and raster drawing for every resize update through mouseMoveEvent. Are these things intended to be recalced so often during interactive resizing (or are they being recalced with too high resolution)? Could there be an option to disable rendering the "live previews" for resizing/scaling as a workaround, if this is too much of a work to fix, it would probably also make the app run better on older hardware. Operating System: Manjaro Linux KDE Plasma Version: 6.5.4 KDE Frameworks Version: 6.21.0 Qt Version: 6.10.1 Kernel Version: 6.18.1-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X3D 8-Core Processor Memory: 128 GiB of RAM (125.4 GiB usable) Graphics Processor: AMD Radeon RX 7900 XTX Created attachment 187691 [details]
gdb-output
Created attachment 187692 [details]
wayland-vs-xcb-demo
|