[Pixman] PDF radial gradients

[Andrea Canciani]

On Fri, Sep 10, 2010 at 8:44 AM, Soeren Sandmann <sandmann at daimi.au.dk> wrote:
> Andrea Canciani <ranma42 at gmail.com> writes:
>
>> I updated the documentation of radial gradients in my wip/radial branch
>> (http://cgit.freedesktop.org/~ranma42/pixman/log/?h=wip/radial) to reflect
>> my changes (which make pixman gradients behave as specified by pdf
>> reference manual).
>
> It's of course important to point out here that changing the radial
> gradients to behave as specified in the PDF spec, really is a change
> from they used to do.
>
> As I understand it, for most common cases, the output is identical to
> what it used be, is that correct? It would be helpful to have a
> description of the cases where the behavior differs.

The behavior is the same when one of the two circle completely contains
the other one, otherwise it is different.
What is the right place for this observation? The code documentation?
Or is it better to write it in the commit message?

>
> Other than that, I'm in favor of just using the PDF spec here. I don't
> think there is much real value in coming up with our own
> specification.
>
> Regarding this:
>
>    When a point does not belong to any of the circles, it is
>    transparent.
>
> It's probably worthwhile to say explicitly that the point has the RGBA
> value (0, 0, 0, 0) instead of transparent. That way it's clear that
> you can't leave out the point when using the SOURCE operator for
> example.

Yes, right.

>
> I'm not completely clear on what cairo is doing (or supposed to do) in
> this case. The cairo SOURCE operator is bounded by the mask, but is it
> also bounded by the source?
In cairo CLEAR and SOURCE are bounded by mask, but not by source.
>
>> The code is not yet ready to be merged (it uses __int128 variables, which
>> probably won't work on 32 bit architectures), but I would appreciate
>> reviews
>> (expecially of the new documentation) and testing.
>
> If __int128 is intended to help with non-FPU systems, then let me
> repeat that using floating point in pixman is totally fine, and almost
> certainly faster than any __int128 would be.

The purpose of using 128 bits is avoiding approximations (thus retaining
full precision), but I also expect it to be faster than floating point, because
in the inner loop the values are updated using multiple differentiation
(i.e. just 3 additions), beside the double-precision computations when
actually needed.

Why do you think that floating point would be faster?
(I expect that int to double conversion is the slow operation in this code,
but it only happens when a sqrt is computed, so it's probably not a big deal)
Did you also consider the changes required to retain full precision?

Thank you for your comments, I'll fix the documentation and benchmark
fixed vs float soon
Andrea