SUMMARY Resizing selections slows to a crawl with Kolourpaint running in Wayland mode. With QT_QPA_PLATFORM=xcb the issue is improved (but not fully solved) STEPS TO REPRODUCE 1. Run Kolourpaint with QT_QPA_PLATFORM=wayland 2. Draw something or open an image 3. Make a selection 4. Resize it (larger resizes make the issue worse) OBSERVED RESULT Resize slows to a crawl but does eventually finish EXPECTED RESULT Resize perfectly follows mouse cursor SOFTWARE/OS VERSIONS Operating System: EndeavourOS KDE Plasma Version: 6.2.2 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 Kernel Version: 6.11.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 4800H with Radeon Graphics Memory: 15,0 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: ASUSTeK COMPUTER INC. Product Name: ASUS TUF Gaming A17 FA706IU_FA706IU System Version: 1.0
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