[cairo] CGContextFlush in the new quartz backend

[Owen Taylor]

On Mon, 2007-03-05 at 17:15 +0100, Richard Hult wrote:
> Hi,
> 
> I have looked into a bit why GTK+ on OSX is much slower with the new 
> quartz backend than it was with the old one.
> 
> The reason seems to be the call to flush the graphics context whenever a 
> surface is finished. This basically means "synchronously push my changes 
> to the screen", which doesn't work well together with how GTK+ uses 
> cairo. A typical GTK+ app can easily create and destroy 20 surfaces when 
> exposed, like when first created or when moving the mouse across it, and 
> this means a flush is called 20 times as well, creating a lot of flicker 
> and you can actually see each widget being drawn to the screen one at a 
> time.
> 
> To me, it would make more sense to leave that part (flushing the 
> context) to the user of the surface, in this case GTK+ and not have the 
> cairo surface do it automatically. Would this cause problems for other 
> users?

I can't answer to what it would do to other users, but the flush there
is certainly against the philosophy of what the other backends do.
Drawing with cairo is supposed to act very much like using drawing
commands in the native API.

 * When drawing in windows, you call BeginPaint/EndPaint around
   your calls into Cairo.

 * In X, if you want to flush buffered drawing commands you have to 
   call XFlush() yourself.

And so forth. What cairo_surface_flush() does is flush out buffered
state that is *internal* to cairo; it thus synchronizes the native
drawing state to the cairo drawing state for the surface.

					- Owen