[cairo] Clip region problems
Owen Taylor
otaylor at redhat.com
Fri Mar 11 13:04:33 PST 2005
* For exact rectangular clips, we change the clip region on the
destination surface, but we don't necessarily reset it
when we are done drawing to the surface.
We also don't do anything to guard against the same surface
being used as the target of two cairo_t, or the target of
a cairo_t and a source for drawing to another cairo_t.
* In libpixman and Render, a clip region set on a source affects
rendering... clipped pixels are treated as fully transparent.
This isn't particularly useful behavior, but because of the
above problems, it will leak out and affect Cairo rendering
in some cases.
So, how do we fix these problems? Ideas:
1. Pass the clip region as an explicit argument to all drawing
functions. If the surface needs to set a clip region, it
sets it, then unsets it afterwards.
Pro: simple
Con: expensive
1b. Pass the clip region as an explicit argument to all drawing
functions, modify pixman_region_t to make it efficient.
If you made pixman_region_t a copy-on-write wrapper for
a refcounted object, then you could easily provide cheap
void pixman_region_copy(pixman_region_t *region)
int pixman_region_definitely_equal(pixman_region_t *a,
pixman_region_t *b);
So, it would be easy for the backend to avoid changing the
clip when it didn't need to.
Pro: fairly simple,
Con: major pixman_region_t changes
2. Have a "drawing state" for a surface. So, something like:
cairo_surface_draw_state_t *cairo_surface_begin_draw (cairo_surface_t *surface);
void cairo_surface_end_draw (cairo_surface_t *surface,
cairo_surface_draw_state_t *state);
And maybe some copy or save/restore functionality to integrate with
the gstate stack.
The idea here is that this would allow the target surface to realize
that two cairo_t's were targetting it and use different Picture
or pixman_image_t objects for each use.
Pro: allows a lot of backend flexibility, extensible to other
similar situations.
Con: complex, makes writing new backends hard, changes all over
the place
3. Kill the rectangular clip optimization, but expose device
space region clips for particular backends. GTK+, would prefer
cairo_xlib_surface_set_clip_region ()
To the current clip API. Maybe users would also be happy with
a surface-based clip.
Pro: Simple
Con: API ugliness, still possible problems using the same surface
as source and dest.
4. Only allow a surface to be used for a single thing at a same time
- two cairo_t's cannot be active for the same target surface
- a surface that is the target of a cairo_t cannot be used
as a source.
Pro: Simple
Con: Fairly big restriction
-------------- 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/20050311/9a3301ca/attachment.pgp
More information about the cairo
mailing list