Re: Results on Claasen's -nocairo patches

[Soeren Sandmann <sandmann daimi au dk>]

"Morten Welinder" <mwelinder gmail com> writes:

> > This program makes the same mistake as gtk-perf: it sends the drawing
> > requests, but doesn't wait for the X server to actually perform them.
> > So you are essentially profiling Cairo and Xlib.  You aren't seeing
> > things like "the X server takes 50% of the CPU time while the benchmark
> > is running".
> 
> I would call excluding the X server a feature.  Sometimes desireable,
> sometimes not.
> 
> There are a couple of situation where you want to do just that:
> 
> 1. Remote X connection, even if we're just talking a local network.
> 2. Multi-CPU machines.
> 
> In either case, X is running truly is parallel with the program.

The thing you should care about is still how long it takes before the
user sees a result. And synchronizing with the server gives you a more
accurate measurement of that than not synchronizing, even when the
server is running in parallel with the client. Of course synchronizing
will skew the measurement because it includes half a roundtrip that
doesn't need to happen, so an even more accurate way would be to look
at property notifies:

        - listen for propertynotifies

        - change a property 

        - do the thing you want to measure

        - change the property again

        - synchronize with the server

        - subtract the timestamps on the two PropertyNotify events you
          got.

The last source of inaccuracy here would then be the time it takes for
the graphics chip to actually process the drawing commands (they are
in many cases emitted asynchronously by the X server). Taking *that*
into account gets trickier, but if the benchmark runs for enough time
and is not doing any 3D stuff, it shouldn't matter too much.


Soren