Playing with KWin's Paint Desktop Effect
Warning: no videos included, though they would help a lot. Also note that I'm using an Intel chipset in both my laptops (the big one also has an ATI chipset, but that doesn't work.)
Lukas recently discovered that Krita was taking about 100% of one of his CPU's cores. When moving the mouse over the canvas. Since X11 took about 60% of that CPU we immediately thought of painting issues, so I started testing with KWin's Paint desktop effect enabled. That effect overlays every rect that is redrawn with a color.
It quickly became clear that for some reason, updating the mouse position lable in the statusbar would update all of Krita's window: menu, toolbars, canvas, toolbox, dockers and statusbar. Curiously enough, Karbon only updates the statusbar. When I disabled the mouse position label in Krita, the CPU usage was gone.
Then I started playing some more, also on my other laptop and now in Ersingen for the KPresenter sprintlet, we tried the same on Thorsten's laptop. And I'm puzzled by the results:
On my X61t, the areas covered by the tooltips of the icons in the system tray is redrawn constantly, all on top of each other. If the panel is visible, and I make Krita full-screen, the area covered by the clock, underneath the Krita window, is continuously redrawn. This runs KDE 4.4.62, on OpenSUSE.
On my W500, the whole screen is constantly completely redrawn. No wonder Desktop Effects feel slow on that laptop! If I make Krita full-screen, no matter whether the statusbar is hidden or not underneath the Krita screen, the redraws are gone. This is KDE 4.4.0 rc3, on OpenSUSE.
On Thorsten's T60 (ATI chipset), we don't see the whole-screen redraws, but we do see a rectangle in the middle of the top-left quadrant of his screen, near, but not exactly at, the place where Thorsten keeps his clock that gets redrawn constantly. This is KDE 4.4.0 final.
But when we are testing KPresenter's animation framework, we see that we only redraw the shapes that are moving, so that's good! (Except when two shapes move, then Qt apparently decides to repaint the whole rect that contains the two shapes.
Well, I'm puzzled, so I'm posting this. Obviously minimizing repaints is trickier than I thought, and it seems especially difficult to limit repaints to the minimum necessary.
