Bug 506240

Summary: Moving cursor increases KWin's CPU usage, especially with higher refresh rate screens.
Product: [Plasma] kwin Reporter: thesword <thesword53>
Component: performanceAssignee: KWin default assignee <kwin-bugs-null>
Status: CONFIRMED ---    
Severity: normal CC: nate, xaver.hugl
Priority: NOR Keywords: efficiency-and-performance, wayland-only
Version First Reported In: 6.4.1   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Moving cursor in Gimp canvas

Description thesword 2025-06-26 21:10:41 UTC
Created attachment 182702 [details]
Moving cursor in Gimp canvas

When I move cursor inside GIMP or Inkscape canvas, kwin skips frames including cursor and uses much higher CPU (50% of 1 thread). This is noticeable on monitors with high refresh rate such as mine which has 360Hz.

STEPS TO REPRODUCE
1. Open Gimp or Inkscape on a high refresh rate monitor (>= 240 Hz)
2. Open vkcube or glxgears on the same monitor with MangoHUD overlay
3. Move the cursor inside the canvas of Gimp or Inkscape

OBSERVED RESULT
MangoHUD overlay shows ~220-240 FPS and a non flat graph
The cursor skips frames

EXPECTED RESULT
MangoHUD overlay shows 360FPS and a flat graph
The cursor doesn't skip frames

SOFTWARE/OS VERSIONS
Linux 6.15.3-arch1-1
Plasma 6.4.1
CPU: AMD Ryzen 7 3700X
GPU: Nvidia GeForce RTX 2080 SUPER

ADDITIONAL INFORMATION
Gnome Wayland is not affected by this issue.
Comment 1 Nate Graham 2025-08-20 18:21:22 UTC
I can also generally reproduce that moving the pointer increases KWin's CPU usage. I have a 120hz screen, and I can believe the effect is more noticeable with a screen that has triple the refresh rate.
Comment 2 Zamundaaa 2025-09-26 17:08:57 UTC
I can confirm that CPU usage is a tad high when moving the cursor in the Gimp canvas, but afaict that's just from constantly updating the window textures - scrolling in a similarly sized Dolphin window causes similar levels of CPU usage (though still less because Gimp doesn't support proper fractional scaling and thus uses a buffer with 2x size).

I don't see any dropped frames on my 120Hz screen, but that could very well just come from texture uploads taking that long. I can't think of anything we can realistically do about it anytime soon if that's the case.
Comment 3 thesword 2025-09-26 21:43:54 UTC
I think the main issue is setting the cursor shape is done in the main thread ans blocks the process. In my case, it takes longer than the frametime which is 1/360s and this is why I see frame drops.
I can reproduce this issue with more visible hitches when loading this page https://threejs.org/examples/webgl_renderer_pathtracer.html which loads the GPU at 100% and changing the cursor shape by hovering the URL bar.
The root cause of this issue is the same as https://bugs.kde.org/show_bug.cgi?id=479250