[cairo] _cairo_gstate_clip issues

[Owen Taylor]

On Tue, 2005-05-10 at 10:54 +1200, Robert O'Callahan wrote:

> _cairo_gstate_init_copy lets the copied gstate share a reference to the
> original clip.surface. But in _cairo_gstate_clip, if clip.surface is
> non-null then we just draw into it. Shouldn't there be some
> copy-on-write code here to create a new copy of the surface if it's
> shared and draw into that? Otherwise popping the gstate can't properly
> restore the original clip.

Yep.

You don't really need much fancy here since the clip surface is
shared only in very well defined ways:

 if (clip_surface->ref_count > 1) 
    /* create a surface the size of the intersection of old
       and new clips, and combine there */

Kristian is working on some more general copy-on-write mechanisms for
cairo_surface_t, but blocking on that would be overkill.

I'd try to come up with a patch, but my tree is a bit of a mess
with the status changes.

> I've been having some problems with non-pixel-aligned clip rects. It
> seems to have been a big cause of the performance problems I was seeing,
> with all those extra composites clip surfaces induce. Life is much
> better now that I'm pixel-aligning my clip rects and the pixman region
> code is used instead. However (1) I won't always be able to do that when
> I start rotating content and (2) I have been seeing bugs where clip
> surfaces don't clip as much as they should (not explained by the
> copy-on-write problem, of course) ... I'll try to track it down.

What sort of problems? One thing to note is that non-pixel-aligned
clips inherently suffer from fringing around the edges (saving FSAA)
if you make a non-pixel-aligned clip, draw a blue rectangle 
past its bounds, then draw a red rectangle past its bounds,you
get a red object fringed with magenta.

So, basically, you can't use them in the same ways as pixel aligned
clips ... if you are doing partial redraws, you need to compute a
pixel aligned clip in some fashion.

If its something different than that, a test case would be wonderful.

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/20050509/61fe8283/attachment.pgp