[cairo] A hidden offset for the xlib backend
otaylor at redhat.com
Sun Sep 5 12:27:16 PDT 2004
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:
&drawable, &x_off, &y_off);
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(),
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
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
- 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.
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040905/ff3a497d/attachment.pgp
More information about the cairo