[whatwg] <canvas> shadow compositing oddities

[Philip Taylor]

On Sun, Jul 27, 2008 at 8:06 PM, Eric Butler <ebutler at mozilla.com> wrote:
> [...]
> However, following the spec's drawing model, there are a few operators that
> behave rather unexpectedly if the shadow color is left at its default value.
> For instance, since A in B always results in transparency if either A or B
> is fully transparent, source-in will always simply clear the clipping region
> to fully transparent no matter what the source and destination are.

Oops - that does seem quite broken. (It's probably my fault - I didn't
notice that problem when I was looking at how shadows should work...)

> It would seem Safari isn't quite following the spec here, since it appears
> to never draw shadows when the shadow color is fully transparent or
> something and doesn't encounter these issues.

As far as I can tell: It never draws shadows when shadowColor.alpha <
1/256, regardless of the other attributes. Also, it never draws
shadows when blur=0 and abs(offsetX) <= 1 and abs(offsetY) <= 1,
regardless of the colour.

In the cases where it does draw shadows, there's also an issue that
its compositor ignores the area outside the shape that's being drawn
(instead of treating it as transparent-black, as is required by the
spec and implemented by Opera and (usually) Firefox) - so in cases
like http://philip.html5.org/demos/canvas/shadow-composite.html with
the source-in mode, WebKit fails to clear the area outside the
shape/shadow to transparent-black. (I'm testing with Safari 3.0.4 - I
hope not much has changed since then). That is probably a sufficiently
unusual situation that it's sensible for the spec to stay as it is and
require WebKit to change, though the spec still needs to change for
the default shadows-disabled case.

-- 
Philip Taylor
excors at gmail.com