[whatwg] Proposal to remove a paragraph from canvas spec

On Tue, 3 May 2011, Matthew Delaney wrote:
>
> The paragraph in the canvas spec that reads...
>
> "Shadows are only drawn if the opacity component of the alpha component 
> of the color of shadowColor is non-zero and either the shadowBlur is 
> non-zero, or the shadowOffsetX is non-zero, or the shadowOffsetY is 
> non-zero."
>
> ...I've found must have been modeled after a bug originally from 
> CoreGraphics. As you can see in this simple animation of a shadow blur 
> being reduced from 20 down to 0, this "edge case" outlined in the above 
> paragraph produces undesirable behavior at the end of the animation: 
> http://webstuff.nfshost.com/shadowblur.html
> 
> This outlined edge case really only affects a particular case of when 
> the composite operation is set to destination-atop, which should result 
> in the shadow landing "on top of" its source, and both the offsets and 
> blur are of course 0. In the animation sample linked above, this case is 
> the end state of the animation (the rect turning all blue all of a 
> sudden).
> 
> Since:
> 
> 1) This behavior is obviously not ideal (see the linked animation above) 
> and is really just a bug
> 
> 2) I can't imagine this particular edge case popping up all that often 
> (think: using destination-atop and having both the shadow offsets and 
> the blur 0 so that the shadow would otherwise be totally eclipsed by the 
> source?)
> 
> 3) The only major browsers I've found to support this edge case are 
> Firefox4 (but not versions less than 4) and CG/Skia ports of WebKit 
> browsers (because this is where the bug originated)
> 
> ...I'm proposing this:
> 
> 1) Strip out this edge case paragraph in the spec (yay, cleaner spec!)
> 
> 2) Notify Firefox team that they should strip out this hack in their 
> code for the edge case.
> 
> 3) Quickly fix WebKit ports
> 
> 4) File a bug against CG on this faulty behavior (just did that) and 
> hope that it can be fixed in future releases.
> 
> 5) Ask philip/W3C nicely to update his/the test at 
> http://philip.html5.org/tests/canvas/suite/tests/2d.shadow.enable.off.2.html 
> http://w3c-test.org/html/tests/approved/canvas/2d.shadow.enable.off.2.html
> 
> I also posted more info here: 
> https://bugs.webkit.org/show_bug.cgi?id=60091
> 
> I realize this is somewhat nit-picky, but it's clearly a bug (unless I'm 
> missing something obvious) that I think we can all quickly rectify. 
> Additionally, I've found a handful of other similar things in the canvas 
> spec that I will write about shortly, but wanted to test the waters of 
> emailing this list first to see how hard it is to push this "easier" 
> issue. ;-)

On Wed, 4 May 2011, Robert O'Callahan wrote:
> 
> See the thread "<canvas> shadow compositing oddities" from July 2008. In 
> that thread, Eric Butler points out that always drawing shadows has 
> problems with operators other than dest-atop. For example, with 
> source-in, always drawing a fully transparent shadow would mean that 
> source-in acts just like clear!
> 
> So as well as being compatible with CG, this behavior was thought to be 
> desirable because it provides a simple way for shadows to be completely 
> disabled by default, without requiring authors having to explicitly 
> enable shadows.
> 
> So here are some options:
> 
> 1) leave the spec as-is
> 
> 2) introduce explicit API to enable/disable shadows (would break a lot 
> of Web content at this point, probably not realistic)
> 
> 3) remove the no-shadow special case, as you suggest (breaks some 
> operators, probably not a good idea)
> 
> 4) remove the no-shadow special case, but add a special case to not draw 
> shadows for operators other than source-over
> 
> I think I prefer #4. I have yet to hear of any use-case that needs 
> shadows with an operator other than source-over, and it would probably 
> simplify the spec and implementations a little bit.

#4 seems fine to me. Does anyone object to #4? I propose waiting until 
browser vendors implement this (to test that it is not a compatibility 
problem), and then updating the spec accordingly.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 12 May 2011 20:19:38 UTC