[cairo] Gradients patches

[Andrea Canciani]

On Mon, Oct 4, 2010 at 12:07 PM, Andrea Canciani <ranma42 at gmail.com> wrote:
> This morning I pushed
> http://cgit.freedesktop.org/~ranma42/pixman/log/?h=radial-for-master
> It should be ready for master since it is documented, tested (at least
> on my laptop) and not using
> any new features (so it should not be broken on other
> architectures/compilers/etc).

As suggested on IRC, I tried to cleanup the patch and improve code reuse.
The result is http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/radial-master
Except for differentiation, there is basically no clever trick and the code
should look quite straightforward and minimal.

Soren pointed out that this change should probably be cross-posted to
cairo and Xorg,
because it changes the radial gradient semantic.
For cairo, it currently causes many failures in the test suite, but
this gradient definition
is probably what cairo actually wants. In fact, it would remove some fallbacks
from backends able to draw pdf-like gradients (pdf, ps, quartz).
I'm omitting the crosspost to the X mailing list because I checked
again the RENDER
extension and it currently only allows radial gradients with one
circle completely
contained in the other one (and in this case the old definition gives
the same results
as the new one).

>
> I'm reviewing the fix for the precision of linear gradients, but I
> noticed that there are some
> (apparently correct) assumptions that I didn't document. I'm checking
> that they are true and adding explanations of why they hold.

Not all of them were actually true, so I took the linear-float branch and
worked on it:
http://cgit.freedesktop.org/~ranma42/pixman/commit/?h=wip/linear-master
I cleaned it up and made it more robust with respect to error propagation.
The performance is just slightly worse than its fixed-point counterpart
(around 10% on x86_64), but it has the big advantage of avoiding all the
overflows.
(For the cairo-interested ones, this fixes gradient-linear-large).

I didn't change linear_gradient_classify (), but it should be corrected or,
if it does not provide a measurable performance gain, removed.
(The code seem to indicate that now the only two meaningful classes
are UNKNOWN and HORIZONTAL).

Andrea