https://bugs.kde.org/show_bug.cgi?id=522257
Méven Car <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |NEEDSINFO CC| |[email protected] Resolution|--- |WAITINGFORINFO --- Comment #2 from Méven Car <[email protected]> --- Thanks for the details (KWin 6.7.1 on Wayland, Mesa Iris Xe on the i5-11300H, ~12 Places entries including a mounted-disk capacity bar, dragging a single text file). I could not reproduce the stutter here — dragging a file over Places stays at 60 FPS on Wayland (Breeze and Oxygen) with release Dolphin. So this looks specific to the compositor/GPU buffer-commit path rather than a general regression, which fits the Intel Iris Xe + KWin-Wayland setup. I profiled a drag anyway (on-CPU sampling + an off-CPU capture of the main thread). During the drag the main thread is almost entirely idle — ~88% of the time parked in ppoll inside the drag's nested event loop (KItemListController::startDragging → QDrag::exec → QEventLoop::exec), and total CPU across all Dolphin threads is only ~20% of one core. So the slowdown is not CPU/compute: the thread is waiting, most plausibly on the Wayland buffer-commit / frame-callback cycle. That explains a drop to ~20 FPS while the CPU stays idle, and why it only happens over Places (the rest of the window is not repainting on every motion event). The one Places-specific cost per drag-move is the drop-indicator repaint: KFilePlacesView::dragMoveEvent() recomputed the indicator and called setDirtyRegion() on every mouse-move event, even while the cursor stayed within the same place and the indicator rectangle was unchanged. Each such repaint commits a new buffer; if the compositor frame-throttles commits (likely on the Iris Xe path under KWin), repainting on every motion event paces the whole drag down to the commit rate. The mounted-disk capacity-bar row makes each repaint heavier (two antialiased rounded-rects + free-space handling), so it's the worst case. Proposed fix: https://invent.kde.org/frameworks/kio/-/merge_requests/2296 — repaint only when the drop indicator actually changes (no behaviour change otherwise). Since I cannot reproduce the slowdown here, I cannot confirm it restores 60 FPS on your hardware — could you build/test it and report back? If it does not fully fix it, the remaining cause is likely the KWin/Qt-Wayland commit path itself (independent of KIO). To pin that down, an off-CPU profile during the drag would help — note it has to be off-CPU, since a normal on-CPU profile just shows Dolphin idle. Two ways: - hotspot (easiest): Record → attach to dolphin → enable "Off-CPU Profiling", drag over Places ~20s, then attach the resulting perf.data. (paru -S hotspot) - or perf record --off-cpu -F 997 --call-graph dwarf -p $(pidof dolphin) -o dolphin.perf.data -- sleep 20 (drag during the 20s) and attach dolphin.perf.data (might be too large to attach). -- You are receiving this mail because: You are watching all bug changes.
