[cairo] Re: cairo gradients

[David Reveman]

On Wed, 2006-04-19 at 15:35 +0100, Jonathan Watt wrote:
> Carl Worth wrote:
> > On Tue, 18 Apr 2006 11:00:21 +0100, Jonathan Watt wrote:
> >> David Reveman wrote:
> >>> For the pixman backend, X server backend and glitz backend the results
> >>> are undefined when some part of the inner circle is outside the outer
> >>> circle. In general cairo tries to expose as few cases as possible that
> >>> can result in undefined results
> > 
> > Yes, cairo definitely does want to avoid undefined behavior.
> > 
> > I didn't realize that that was what we got when the smaller circle
> > intersects or is outside the larger circle.
> > 
> > There shouldn't be any requirement for undefined behavior here. For
> > example, PDF provides a two-circle specification of a radial gradient
> > and carefully defines the result when one circle does not entirely
> > containt the other, (giving the appearance of inward-pointing cone if
> > the first circle is smaller and an outward-pointing code if the first
> > circle is larger).
> > 
> > The PDF semantics seem quite reasonable to me. So if someone wants to
> > fix things, I don't see why we wouldn't follow that. We can put the
> > new implementation into libpixman and avoid X server gradients when
> > they are not compatible, (currently cairo is always avoiding X server
> > gradients).
> 
> I'm not clear on what this means for Mozilla. Does this mean that cairo isn't 
> going to clamp the smaller circle, and so the clamping will need to happen in 
> Mozilla code? I don't mind either way, but I'd like to know whether I need to 
> provide a clamping patch for Mozilla.

Well it means you don't have to clamp at all if you don't want to. Cairo
will provide well defined results for values that are not clamped.

-David