[Pixman] PDF radial gradients

[Soeren Sandmann]

Andrea Canciani <ranma42 at gmail.com> writes:

> 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?

The commit message, I'd say, though it's probably a good idea to also
CC the X and cairo lists to make sure they know this is happening.

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

Okay, if it's necessary for precision, that's fine. I haven't looked
at the code yet.

> Why do you think that floating point would be faster?

I'd guess on most systems, arithmetic on floating point values will be
much faster than arithmetic on int128s, simply because an int128 would
have to be built up from two 64 bit, or four 32 bit registers.

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

Thanks for fixing the gradients btw. At this point they are by far the
most embarrassing part of pixman.


Soren