On August 27th, 2011, 4:45 p.m., Philipp Knechtges wrote:

kwin/composite.cpp (Diff revision 1)
Pixmap Toplevel::createWindowPixmap()
712	QRegion damage(e->area.x, e->area.y, e->area.width, e->area.height);	714	if (damageRatio == 1.0) // we know that we're completely damaged, no need to tell us again
		715	return;

Sry for the late comment, but shouldnt we at least drop the damage events from the event queue.

On August 27th, 2011, 9:34 p.m., Thomas Lübking wrote:

"Why"? afaik the queue is wiped with the next cycle anyway and testing didn't show any difference in the XPending() count whether i remove the damage events or not
(Surprisingly the performance doesn't improve either - at least not significantly)

Do you spot any leaks or other issues?

On August 27th, 2011, 11:37 p.m., Philipp Knechtges wrote:

My concern was just of theoretical interest. I just wasn't aware that these events are wiped out at the end of the cycle and believed therefore that the damage events would be scheduled as unnecessary repaints in the next frame. But I'm still curious where exactly kwin tells the X Server to clean the event queue because we never call XSync(display(), true) directly?

Nowhere. I frankly thought Q/KApplication would. However *another* test (different debug code) simply blocked compositing completely w/o dropping the events, so
a) good catch - thanks alot
b) check http://commits.kde.org/kde-workspace/562cabc9e76c8af356a68e91147934e80ae4e78b
c) I'm gonna inspect the Qt event management to know for sure ;-)

- Thomas

On July 5th, 2011, 10:32 p.m., Thomas Lübking wrote:

Client updates are expensiv to the compositor.
While KWin limits the framerate (vsync or not) the client still can send a bazillion damage notifications between two frames w/o any gain on screen.

So far the handling is pretty expensive.
a) KWin would handle the damage notification even though the window is still tagged completely damaged.
b) It uses QRegion operations, though we know that the rects in the damage notification won't overlap (and the region is added rectwise, causing more QRegion ops anyway)
c) it allows up to 200 rects but doesn't care about the damage ratio before the window is "just completely damaged"

The patch changes this.

Target are high frequently updating clients, possibly using XShape.
@Martin: do you recall that Java IDE you confirmed to perform horribly under composition? Can you test it against this patch?
Are there still known clients using XShape for text DnD?

I tried (and actually figured the problem) phoronixing KWin against Mutter (wanted to know about all that FUD) and figured that Mutter did actually "better" until i turned off the resize handle (Bespin, but Oxygen has a comparable thing) which causes glxgears to damage in 12 rects. ("only")

In consequence of the patch the kwin CPU usage dropped from constant overall 25% to constant 15% (and the 10% being distributed to glxgears and X11) - ie. a 40% improvement (and higher framerates!!)

Yes, i know that glxgears is special, no i'm not optimizing towards phoronix results, yes Martin, i've read the article - not that it was new to me ;-)

Yes, phoronixing.