[cairo] Radii of radial gradients

[Carl Worth]

On Fri, 23 Feb 2007 14:04:11 -0600, "Michael Urman" wrote:
> 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.

You're quite welcome. As for atmosphere, I'm also very pleased with
the community that has formed around cairo. It's just a whole lot of
really smart people who all seem to have fun working on these
interesting problems together. I love it! So thanks to everybody for
making this such a great place to hang out, (virtually at least---at
some point we'll need to make a really concerted effort to get as many
cairo folks together in person as we can[*]).

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

That could be really helpful. The most obviously correct code really
shouldn't be that hard to write, and even if it were slower than we
wanted for a final implementation, would be great for generating
reference images to test a more optimized implementation against.

So, please let me know if you come up with something.

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

When you go read the PDF specification, you'll see that you get
different results depending on which direction you go. So, instead of
"inner" and "outer" we should talk about the "initial circle" and the
"final circle". That way, either one can be smaller or larger, and the
user can control the desired effect.

Your description is quite similar to what the PDF model
describes---namely drawing circles sequentially from inner to outer,
(at least conceptually).

> I don't see a model problem with the slight position change leading to
> a change between sphere and cone modes,

Well the problem that can be caused here is if some unrelated event
triggers the transition. For example, one might be zooming in or out
in a program like inkscape, and different rounding at different zoom
levels might trigger arbitrarily large portions of the drawing to be
colored differently.

That seems like something we really don't want cairo to be doing.

Interestingly, when one of the circles has a radius of 0.0, the
borderline occurs right when that circle is positioned exactly on the
other circle. And, in the case of SVG, that is precisely where an
out-of-bounds focal point gets snapped to. So I am still quite curious
to see what existing SVG implementations do in that case.

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

The notion of sequentially drawing the circles should do the trick for
defining the correct result for the "overlapping" portions.

So, the simplest code would look something like this:

    For each position (x,y):
	Solve radial gradient equation for (color, time) given (x, y)
	If there are two solutions compute color2 OVER color1,
	    (where color2 corresponds to time2 > time1)

> Looking forward to seeing the inconsistencies fixed,

Yes, me too.

I'm first going to ignore this really interesting case we're
discussing here and try to fix the original "inner radius" bug. But
I'll have to get some sleep first.

-Carl

[*] I happen to be at FOSDEM now, and had the pleasure of being
introduced to Alp Toker tonight---after he had been in my hotel room
for several minutes with neither of us realizing who the other
was. That was a lot of fun. If anyone else is here at FOSDEM, please
make sure I get to meet you, shake your hand, and thank you! It would
be a shame if we didn't end up connecting if we were so close.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070223/22368982/attachment.pgp