[cairo] Radii of radial gradients

[Michael Urman]

On 2/23/07, Carl Worth <cworth at cworth.org> wrote:
> I probably should have replied at this point in the thread earlier. I
> wanted to thank you for originally reporting the bug (months ago!) and
> also following multiple times with other poor users that also hit the
> same bug and providing them a useful workaround.

No problem. Thanks for all the efforts you (and everyone else) have
put into cairo so far. If I were working on projects that needed this,
I would probably have jumped in to figure out what's going on. I
appreciate the atmosphere you cultivate for this project.

> Since I'm now thinking about fixing radial gradients, I'm thinking
> about that case as well. And the question is, what do we actually want
> to draw in that case? And the answer isn't immediately obvious.

Tempting though the simplicity of the SVG behavior is, like you say
it's too limiting. The description of PDF sounds a lot more like what
I had in mind. I'll see if I can go play with some test
implementations tonight or tomorrow, and read up further on the PDF
behavior, but here's the mental model of what I expected to happen
when I was first trying to use radial gradients.

Given radii r0 and r1, centers c0 and c1, and g(t) defined explicitly
for t in [0,1] looking up the gradient color (and extended beyond), I
would expect the gradient source to act similarly to one from drawing
an infinite sequence of circles with infinitesimal stroke width,
interpolating their radii r = (1-t)t*r0 + t*r1 and centers c =
(1-t)*c0 + t*c1, and using the gradient color g(t).

What I'm not sure is in the case where those circles overlap, whether
they should be drawn outer to inner, or inner to outer. It sounds like
the cone effect requires outer to inner. You'll note my mental model
gives no strong meaning to "inner" and "outer" radii, as except in
this overlap case, they are equivalent.

I don't see a model problem with the slight position change leading to
a change between sphere and cone modes, although I could certainly
imagine performance concerns requiring different code paths. I also
could imagine it needing certain Porter-Duff composition options to
avoid getting muddy in translucent cases.

Looking forward to seeing the inconsistencies fixed,

Michael
-- 
Michael Urman