<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - [X regression] aa10text performance reduced ~12% with gnome-session" href="https://bugs.freedesktop.org/show_bug.cgi?id=70948#c11">Comment # 11</a> on <a class="bz_bug_link bz_status_NEEDINFO " title="NEEDINFO - [X regression] aa10text performance reduced ~12% with gnome-session" href="https://bugs.freedesktop.org/show_bug.cgi?id=70948">bug 70948</a> from <a class="email" href="mailto:eero.t.tamminen@intel.com" title="Eero Tamminen <eero.t.tamminen@intel.com>"> Eero Tamminen</a> <pre>(In reply to wendy.wang from <a href="show_bug.cgi?id=70948#c10">comment #10</a>) > 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 <a href="show_bug.cgi?id=70948#c8">comment #8</a>) > Yes, that was exactly the change. I think the culprit is > > commit 9bf46610a9d20962854016032de4567974e87957 > Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>