[cairo] A hidden offset for the xlib backend

[Owen Taylor]

Code that combines GTK+ with Cairo has to deal with the GTK+
double-buffering code that invisibly redirects drawing operations
on windows to a backing store pixmap during an expose event.

The way that you'd generally do this is:

   gdk_window_get_internal_paint_info (window, 
                                       &drawable, &x_off, &y_off);
   cairo_set_target_drawable (cr, 
                              GDK_DRAAWABLE_DISPLAY (drawable), 
                              GDK_DRAWABLE_XID (drawable));
                                                                                                                                                                                             
   cairo_translate (cr, -(double)x_off,-(double)y_off);

But the problem here is that this translation does leak out to
the user if they use, e.g, cairo_transform_point(), 
cairo_inverse_transform_point().

Does adding the ability to have an extra offset in the Xlib drawable 
that is added on to the effect of the CTM sound plausible? It's 
obviously a little ugly, but I think it's hard to do without.

Hmm, while I'm thinking about such subjects, there are some other
additions that would be nice from a performance point of view:

 - The ability have an additional rectangle-list clip in the
   Xlib surface. Frequently during an expose event, GTK+ is
   drawing L shaped areas

         XXXXXX
         X.....
         X.....

   And passing the real clip to the server is going to save
   a lot of pixel operations that will be thrown away.

 - The ability to pass in a width/height to cairo_xlib_surface_create()
   to avoid a round-trip. (Round-trips are bad to the point where
   querying the the server is something you don't want to do in
   production software)

 - More of a future thing, the ability to hint to to cairo that 
   the contents of the Xlib surface passed to  
   cairo_xlib_surface_create() are a solid fill ... this is
   very much the normal case for GTK+ usage and allows for
   big optimization in the no-RENDER case. 
   (see http://mail.gnome.org/archives/gtk-devel-list/2003-March/msg00045.html

But the offset is my main initial concern since it affects application
API rather than being just an optimization. I'd be willing to do a patch 
if the idea passes muster.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040905/ff3a497d/attachment.pgp