[Bug 70948] [X regression] aa10text performance reduced ~12% with gnome-session

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=70948

--- Comment #11 from Eero Tamminen <eero.t.tamminen at intel.com> ---
(In reply to wendy.wang from comment #10)
> Hello Chris and Eero,
> I can download the xresponse tool now.
> But which kind of scenario you'd suggest to catch using xresponse? mouse
> click, drag or others?
> 
> Then pls guide me which commits should be measured? Both before and after
> culprit commit?

You would need to check average interval between XDamage events during the
test-run, from output of:
  xresponse -a '*' -w 0

(monitored applications (-a) are all (=*), wait (-w) infinitely (=0))

Run the program from ssh console so that its output doesn't disturb your
testing.  For that output you can also see if something else is doing screen
updates (e.g. panel applets).


I checked x11perf a bit in my Ubuntu.  I don't see XDamage events for x11perf
window itself, maybe because it's override redirect.  I do seem them for
compositor though (SCREEN ones in xresponse output).

x11perf window size is 600x600, and resulting Unity compositor updates on
screen are fullscreen according to XDamage events (no partial screen update
support).  With Unity, those screen updates do happen at ~60 FPS (= at ~17ms
interval).

Wendy, what is the average update interval with your gnome-session?


(In reply to Chris Wilson from comment #8)
> Yes, that was exactly the change. I think the culprit is
> 
> commit 9bf46610a9d20962854016032de4567974e87957
> Author: Chris Wilson <chris at chris-wilson.co.uk>
> Date:   Fri Jun 21 22:58:31 2013 +0100
> 
>     os: Immediately queue initial WriteToClient
> 
> which would have had the effect of sending more damage events to the
> compositor.

Ok, so there are actually more of them, they aren't just (potentially) spread
(time-wise) differently.


> And if the compositor was not coalescing them back to the
> equivalent of the earlier stream, it would process more frames. (E.g.
> if it was effectively doing a do { while(read(X)) accumulate(); render(); }
> while(1), it would be processing more work than if it just rendered at a
> maximum frequency.)

Compositor not coalescing the events, would be a (performance) bug in the
compositor.

Wendy, if that is the case (SCREEN updates happen more frequently than 60 FPS),
*and* that is not fixed in latest version of the gnome-session compositor, file
a bug to upstream about it.   We don't want to debug compositor issues.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20141124/0f98fd39/attachment-0001.html>