[cairo] Patch: speeding up _cairo_fixed_from_double

David Reveman davidr at novell.com
Wed Oct 5 15:27:16 PDT 2005


On Wed, 2005-10-05 at 14:35 -0700, Carl Worth wrote:
> On Wed, 05 Oct 2005 17:20:32 -0400, David Reveman wrote:
> > I'd like to use the gradient code in libpixman/xserver instead. I think
> > that that code is already a lot faster than the gradient code in cairo
> > as it's using color spans but I think it's also using color spans when
> > it shouldn't which we'll have to fix. 
> > 
> > We should throw away my old gradient code in cairo. I never tried to
> > make it really fast but for not containing any code for special cases
> > that are easy to optimize, it's not that bad.
> 
> Oh, throwing away code is almost always the best solution.
> 
> I didn't know or had forgotten that we have gradient code just sitting
> here in pixman already. It's good you mentioned this before I
> reinvented something similar.
> 
> Do you have a patch for cairo to use this, or some guidance in
> implementing it? (I know that you offered a patch that extends cairo's
> repeat modes which I haven't yet looked at closely enough, but I
> didn't see a switch to changing the gradient code there when I just
> looked).

I've been planning to create a patch for this for some time now, just
haven't had the time yet.

xlib backend should of course use the gradient implementation in
xserver, which eventually will be accelerated in similar ways to glitz.
Gradient fall-backs will always go through libpixman and it's important
that:

gradient IN shape OP dest

ends up as:

tmp = gradient IN shape (by libpixman)
tmp OP shape (by backend)

when possible as having access to the shape mask in libpixman and not
doing gradient calculations for pixels with shape alpha == 0 is probably
going to be the biggest performance improvement (especially for things
like thin diagonal lines).

> 
> And what are the "using color spans when it shouldn't" problems that
> need to be fixed?

Last time I looked and commented on the gradient patches that went into
xserver they were always using pre-calculated color spans for every
gradient and every possible transformation matrix. I could easily create
a gradient and a transformation matrix that would make the default color
span generate completely wrong results.

However, I haven't looked at the gradient code in xserver for a while so
I'm not 100% sure that it hasn't been fixed.


-David



More information about the cairo mailing list