[whatwg] <canvas> shadow feedback

[Ian Hickson]

On Tue, 29 Jul 2008, Oliver Hunt wrote: 
> 
> We could special case opacity 0, with 0,0 offset, and 0 blur radius as 
> being a "do not draw shadow" flag perhaps?

Done.


On Mon, 4 Aug 2008, Eric Butler wrote:
> 
> The need to be able to disable shadows explicitly seems clear. But I 
> also believe that the spec should provide for a means to disable normal 
> drawing and only draw shadows to increase the usefulness of shadows.
> 
> As it stands, if you draw with shadows, you'll end up getting some of 
> the shadows drawn on top of some of the actual shapes. But perhaps the 
> developer wants to have all shadows behind all shapes for a particular 
> set of shapes. The only way to accomplish that would be to create a 
> second canvas, do all the drawing without shadows on that, then draw the 
> canvas with its shadow back to the original, which seems cumbersome to 
> use and is terribly inefficient.
> 
> It would be simpler if the user could simply turn on only shadows, do 
> the drawing once, then turn on only normal rendering and do the drawing 
> again. You cannot simply set the fill/stroke style to transparent for 
> the same reason that it doesn't quite work for shadows. So I believe 
> that the spec should provide for the means to explicitly disable both 
> shadows and normal drawing separately.
> 
> To that end, perhaps there could be an attribute which indicated what 
> the current state of the drawing model was: object only, shadow only, or 
> objects and shadows, defaulting to drawing only objects. This would 
> create more expected output for all composite operators, and would allow 
> developers to do some more complex tricks with shadows.

On Mon, 4 Aug 2008, Vladimir Vukicevic wrote:
> 
> I think that'll cause problems as well -- for example, let's say you had 
> two overlapping paths that you wanted to draw a shadow behind.  The two 
> paths are both solid and are supposed to be rendered as a single shape 
> to the user.  If you drew them separately with shadows, as it stands 
> now, the shadows would end up adding and would be denser in the overlap 
> areas which isn't what the author would intend. I would suggest: [...]
> 
> - if shadows aren't off, draw them normally -- one shadow per drawing 
> operation
> 
> - go the whole way and add beginLayer/endLayer, akin to 
> CGContextBeginTransparencyLayer[WithRect]/EndTransparencyLayer.  Could 
> also call it pushGroup/popGroup.  As a side benefit, this would provide 
> a simple way to implement double-buffered rendering without needing to 
> use two canvases. 
> (http://developer.apple.com/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#/ 
> /apple_ref/c/func/CGContextBeginTransparencyLayer)

I haven't done this yet but this does seem like the way to go long-term. 
I've added a "v2" note in the spec suggesting this.


On Sat, 28 Mar 2009, Philip Taylor wrote:
> 
> Do the APIs not provide enough features so you can implement shadows 
> yourself? e.g. Firefox uses Cairo which doesn't have any native support 
> for shadows; but it can draw shapes onto an alpha-only surface, manually 
> blur the pixels (if you can implement getImageData then I assume you 
> must already have access to the raw pixels and can do the blurring 
> efficiently), then draw the shape again, and composite everything 
> appropriately, which results in a correct shadow implementation. I don't 
> see what makes this fundamentally harder than implementing all the other 
> required canvas features.

On Wed, 8 Apr 2009, Charles Pritchard wrote:
> 
> The HTML Canvas Shadow specification requires implementors to create a 
> procedural shader hook. This added complexity is a significant cost in 
> time, and brings very little reward. Further, the functionality can be 
> implemented by the user, with the ImageData API. It clutters the 
> namespace with unnecessary variables, it's in some ways intended to 
> gracefully degrade, and that's a backward step from what Canvas has 
> evolved to.
> 
> Shadows are not in wide use, I don't think it's a very controversial 
> part of the specification, for anyone but implementors.

Shadows used to be optional, but having optional features is generally not 
desired, and multiple browser vendors have said they're willing to 
implement the feature. This is basically the bar for adding features, so I 
haven't removed the feature from the spec.

I understand that it might be difficult to implement, however, 
haveingmultiple vendors willing to implement something is rare enough that 
we don't tend to ignore those opportunities.

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