[cairo] clip stack composition performance

[Alexander Larsson]

On Fri, 2005-06-10 at 09:40 -0700, Carl Worth wrote:
> On Fri, 10 Jun 2005 10:33:33 +0200, Alexander Larsson wrote:
> > It turns out that a lot of the time is spent in the general compositor
> > code doing PIXMAN_OPERATOR_IN on the a8 clip masks when clip regions are
> > stacked on top each other.
> 
> Yes, we've known for some time that a fast-pathed IN operator was
> missing. It's actually encouraging to see expected thins showing up in
> the profiles.

Good.

> >                                                       (Although owen
> > said I shouldn't touch the libpixman compositing code until the new
> > compositing code from the X server is merged...)
> 
> The approach I've been taking most recently with libpixman is that
> xserver/fb is the canonical upstream source for libpixman files. I'm
> intentionally ignoring any other X server tree with respect to
> libpixman.
> 
> Also as things are merged from xserver to libpixman, libpixman files
> should be changed to look like xserver files as much as possible,
> (eg. removing any gratuitous renaming that had been done in libpixman,
> except without changing the libpixman public API).
> 
> So if you can get this patch working and committed to xserver/fb
> first, that would be fantastic. And then there is no question about
> accepting it in libpixman. I don't think you would even need to wait
> for any merging of any other code first, (though it might be easier to
> re-sync libpixman with xserver/fb first anyway).

I don't even have the xserver tree checked out here, but i might take a
look at doing this next week.

> If we ever do commit new code to libpixman that isn't already in
> xserver, then this introduces a bug in libpixman, and a bugzilla entry
> for libpixman shall be opened at bugs.freedesktop.org.
> 
> > -  doPath (state, state->getPath(), gFalse);
> > +  doPath (state, state->getPath(), gTrue);
> 
> So what is that doing, anyway?

It rounds all the clip path coordinates (which in general are clip
rects) to integer coordinates.

> As for the actual patch here, the structure looks fine as far as I can
> tell. I can't comment much on the implementation, but I could run it
> through some testing.

Running it through some basic testing would be nice.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an ungodly hunchbacked card sharp on a mission from God. She's a 
cold-hearted hypochondriac mechanic with a knack for trouble. They fight 
crime!