[cairo] [Pixman] Gradients patches

[Soeren Sandmann]

Andrea Canciani <ranma42 at gmail.com> writes:

> > Indeed, the code looks mostly fine to me; I couldn't find any
> > functional problems with it. The main complaints I have:
> >
> > - In the affine case, some of the computation is done in 32.32, and
> >  some in double precision. Is there any reason for this? Doing all of
> >  it in double precision would let us get rid of the dot() function
> >  and the fdot() one could then be renamed to just dot().
> 
> To keep the whole precision, using 32.32 is needed. If we want to use
> double there, we should at least stop doing the differences trick (and still
> the precision would be lower).

Aside from the formatting issues mentioned in IRC, I think the latest
code is probably fine.

We will need to find out exactly what numerical guarantees should be
given and then add tests to the test suite to verify that we meet them
in both the affine and the projective. However, simply having a
well-defined specification for the radials is a big step forward.

> > I think this *does* need to be cross posted to xorg-devel because even
> > though the spec says that it only allows gradients where one circle is
> > contained in the other, in practice, it doesn't check for that. And
> > cairo does not check that the circles are contained within eachother
> > before sending them off to the X server.
> 
> I see that now xorg-devel is in the CC addresses, anyway Cairo should pay
> more attention to what it does. Latest RENDER specification says:
> The array of stops has to contain values between 0 and 1 (inclusive) and
> has to be ordered in increasing size or a Value error is generated. The inner
> circle has to be completely contained inside the outer one or a Value error is
> generated.

It would be useful for someone to update the Render spec to say that
the radials are PDF Type 3 Shadings, defined in section 8.7.4.5.4 of
the PDF specification, and delete the stuff about the circles being
contained in each other.


Soren