[cairo] _cairo_gstate_clip issues

[Owen Taylor]

On Tue, 2005-05-10 at 12:07 +1200, Robert O'Callahan wrote:
> On Mon, 2005-05-09 at 19:50 -0400, Owen Taylor wrote:
> > On Tue, 2005-05-10 at 10:54 +1200, Robert O'Callahan wrote:
> > > 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.
> 
> A rotated HTML box with CSS 'overflow' not equal to 'visible', for
> example. Or just SVG clip-to-path.
> 
> Gecko could clip by drawing to an intermediate surface and compositing
> that back under the clip region in one go (assuming no fancy operators
> are being used). That would not only fix the fringing, it would also
> probably be a lot faster when the clipped content is complex. 

The proposed cairo group API should make this pretty convenient.

> The problem is that's overkill for the case where pixman regions can handle
> the clipping. I suppose I can detect when the clip area in device
> coordinates is a pixel-aligned rectangle and avoid the intermediate
> surface for that case, assuming cairo's going to do the right thing.
> OTOH, wouldn't it be nice if cairo did this itself? :-)

It's probably possible for cairo to do this ... basic algorithm:

 - create a temporary destination surface at the same size as the
   clip surface
 - copy to that surface from the parent surface
 - create *another* temporary surface with the original contents
   of the parent surface.
 - Do operations on the first temporary surface
 - Copy back after every operation
 - When copying back, use the clip mask to blend between the 
   two temporary surfaces

You could avoid the "after every operation" using the proposed
cairo_flush(). You can also with some more cleverness avoid
the second temporary surface in many cases. But it's complex 
however you slice it. (Add in successive clips, save()/restore(),
etc.)

And it *still* doesn't give you the ability to do partial updates.

						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/98fb869d/attachment.pgp