(sorry, can't reply directly, marcan_42 comment is too deep in the tree) > which tells me this isn't a simple pixel pushing problem but rather something mo

(sorry, can't reply directly, marcan_42 comment is too deep in the tree) > which tells me this isn't a simple pixel pushing problem but rather something more profound in Audacity. That's probably because of the cursor animation (when you play). Audacity has to redraw the entire track widget each time the needle moves unless they implement special double buffering + special damage area slices. By default, Qt/GTK/wx are too dumb to understand layers properly. They will redraw the entire rectangle if you try to stack things with any transparency or non-rectangle clips. Even with proper double buffering, combining both frame buffers is still done on the CPU. That's 2x4x{width}x{height}x{fps} bytes up load to the GPU per second. for a 4k ARGB8888 video frame @ 60fps, that's like 4GB/s of raw transfer if you rasterize each frames in the CPU. (disclaimer: former KDE dev) edit: If you run KWin, you can enable the redraw compositor plugin and see for yourself which area of the window are repainted.