[cairo] _cairo_gstate_clip issues

[Robert O'Callahan]

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
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? :-)

Rob