[cairo] clip stack composition performance

[Carl Worth]

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.

> Just for fun I added some special case code for a8 IN operations to
> libpixman, see attached (not very well tested) patch.

Thanks for contributing!

>                                                       (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).

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?

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.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050610/7bb8c029/attachment.pgp