[cairo] Re: Re: 1.1.6 to 1.2.0 performance

[Owen Taylor]

On Sat, 2006-07-15 at 08:30 -0700, Ian Osgood wrote:
> On Jul 15, 2006, at 1:22 AM, Jason Lynch wrote:
> 
> > On Fri, 14 Jul 2006 23:30:27 -0700, Vladimir Vukicevic wrote:
> >
> >> Hmm, so we just recently found that the flush was being hit often  
> >> from
> >> some font code -- try disabling the implementation of xlib_flush, or
> >> just comment out the XSync, and see if that fixes things?
> >
> > Doing that does restore the gtkperf tests to their previous levels,  
> > and as
> > far as my limited testing showed, x-chat scrolling was back to its  
> > normal
> > speed.
> >
> > Jason
> 
> I've been working on the XCB backend, and implemented flush there
> using XCBFlush (asynchronous) instead of XCBSync (synchronous).
> 
> What is the purpose of this backend hook?  If a flush really is required
> for some reason, then there should be a failing unit test once you've
> disabled it.

I really don't think there should be any XFlush() or XSync() here ... 
cairo_surface_flush() should only worry about flushing out internal
cairo state; doing anything else is taking options away from the
application. In the rare case that a XSync() is necessary (for timing,
say, or because you are about to talk to another app over a non-X
IPC channel), the app can choose to do it.

An XFlush() is probably mostly harmless, since about the worst thing
that it can do is trigger a context-switch to the X server to buffer
requests there, but (as the timing people have done proves), XSync() is
a total performance killer and almost always wrong.

Regards,
					Owen

(I guess the argument for the XFlush() is that someone could do:

 - draw to a window
 - flush()
 - sleep
 - draw some more

But that's a fairly broken way of writing an X application. I still
think cairo_surface_flush() should be about internal cairo state and
it should be up to the app to call XFlush() if necessary.)