Re: createRadialGradient when the start and end circles do not overlap

Frank Olivier wrote:
> Hello public-canvas-api
> 
> I'm seeing very different createRadialGradient behavior between the 4
> browsers that implement canvas today - in the scenario where the
> start and end circles do not overlap. See attached document for more
> details.
> 
> From my reading of the spec, it seems that a 5th behavior is
> actually correct - see the quick mockup on the right. This is in
> keeping with the concept of creating a cone, using a set of
> concentric circles.

Safari's behaviour is correct, by my reading. (The current spec text was 
  intentionally written to match Safari - see e.g. 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011186.html)

http://philip.html5.org/tests/canvas/suite/tests/index.2d.gradient.radial.html 
has tests which I believe match the spec, and Safari on Windows passes 
most of them (except for 2d.gradient.radial.inside3 (where a bug was 
introduced in the OS X 10.4 -> 10.5 transition, if I remember 
correctly), and some where it's slightly the wrong shade of green (maybe 
these tests should be more tolerant)).

In particular:

The algorithm as specified draws circles starting at offset +Infinity, 
going to -Infinity, and not overwriting pixels that have already been 
drawn. So the higher-offset colour (blue in your example) is drawn on 
top of the lower-offset colour (red).

Since it goes to -Infinity (or as far as it can with positive radius), 
the lower-offset colour is drawn all the way up beyond the first circle.

Since it just fills circles, areas outside the cone are not painted at 
all and should not be blue. (There's an explicit note that it leaves 
"areas outside the cone untouched by the gradient (transparent black)".)

> imho I think it would be useful to clarify this scenario in the spec
> (the behavior in this scenario should be defined clearly, or marked
> as undefined; don't depend on it) - thoughts?

My thoughts:

I don't like any undefined behaviour (people will depend on it 
regardless of what the spec says, and interoperability will suffer), so 
it should be defined clearly (and implementations should be fixed to 
follow it).

I believe the current specification is unambiguous - you could convert 
the algorithm description directly into code to get the correct answer 
(though it may be hopelessly inefficient), and it handles all the 
possible edge cases.

I believe it's probably the best choice of behaviour to specify in order 
to get sensible output and interoperability (eventually). Safari already 
conforms to it; Firefox could if it clipped the gradient to the cone, 
and fixed some other edge cases; Opera and Chrome look clearly bogus 
since they're not drawing a gradient between the circles.

There might be ways to make the spec easier to understand here, if 
mailing lists and test cases and external demos are inadequate, in which 
case it would be good to improve it, though I don't have any ideas 
myself on how it could be phrased.

-- 
Philip Taylor
pjt47@cam.ac.uk

Received on Friday, 30 October 2009 19:50:48 UTC