[whatwg] <canvas> shadow feedback

[Charles Pritchard]

Ian Hickson wrote:
> 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.
>   
Should the specification require a particular error be thrown, if 
shadows are not supported,
and the user attempts to set a shadow attribute to a non-zero value?


> 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.
>>     
From: 4.8.11.1.6 Shadows

"Shadows are only drawn if"

Current wording suggests any shadow style will enable shadow drawing.
Shouldn't this require that shadowColor have a non-zero alpha component?

Later on:

"7. The shadow is in the bitmap B, and is rendered as part of the 
drawing model described below."
There doesn't seem to be a drawing model described for working with 
bitmap B.

Do shadows work with drawImage / CanvasPattern ?

> 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: [...]
>>     
Is this still an issue in the spec? It doesn't seem to be an issue to me.

>> - 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.
>   
Did this note go anywhere?
Graph in v2 would be useful, should GPU support be enabled.
Here are some basics:

CanvasGraph {
 createGlyph  /* useful for implementations that require shape 
tessellation */
 createPattern /* ensures the image/canvas/pattern is accessible in 
immediate mode / cache */
 createShader /* wishful thinking */
 glyphAtPoint(x,y) // I don't know
}


> 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
I don't think there should be optional sections in this initial 
specification.
I'd like to see Canvas supported in a wider context than the three main 
vendors.
I still see shadow support as a barrier to entry, in that regard.

I appreciate the effort it must take to get the big three to agree on 
anything.

It seems to me that browser vendors are quite accepting of the WHATWG 
standards for Canvas support.
The vendors are also experimenting with Canvas support. Gears has 
experimental filters [color matrix, etc],
Firefox has SVG effects for Canvas (Does this work with toDataURL?). It 
seems these efforts
are currently being ignored.

If a Gaussian blur into a second bitmap is required logic for a proper 
canvas implementation,
then the specs should go the whole way: add color transform and 
convolution transform.
They're durable and in wide use in other contexts.

With shadow support already enabled in a project, it would take minimal 
effort to support two additional filters.
The only reason they are not currently supported (in my mind), by 
Firefox 3.5,
is that they are not a part of the Canvas specification.

I think it can be done with little effort for any package already 
supporting Shadow.

Major vendors [supporting shadows] could easily support a derivative of 
the following interface,
were it to be added to the Canvas specification, in place of the shadow 
support section.

If we're not going to take shadow support out of the specs,
is there room to move forward, adding in these two additional transforms,
and improve upon the current shadow API?


Initial Draft of "Shaders"

shadeStyle {
 compositionMode: source-over (default) | source | destination | 
...globalCompositionModes
 component: alpha | rgb | rgba
 alphaColor: [css color]
 offsetX:
 offsetY:
 blur: [currently shadowBlur]
 colorTransform: colorMatrix[]
 pixelTransform: convolutionMatrix[], divisor, bias
}

When compositionMode is set to source, filters are not rendered.
When it is set to destination, only the output of Bitmap B is composited
onto the canvas. Other composite modes apply per current specification.

globalCompositionMode would still apply post-composite of Bitmap A and 
Bitmap B.

Component declares which color components of Bitmap A are copied to Bitmap B
prior to filters being run.

Filters run on the contents of Bitmap B in this order:
blur, color transform, convolution matrix, alphaColor.

A filter need not be run if it would not effect the value of Bitmap B.

Current shadow support would be written as:
 compositionMode: source-over
 component: alpha
 alphaColor: rgba(0,0,0,0)
 blur: 0
 offsetX: 0
 offsetY: 0

colorTransform would typically be:
 compostionMode: destination
 colorTransform: colorMatrix[]
And used with fillRect<CanvasPattern>

alphaColor can be used with different component
options and color matrixes to implement thresholding,
or otherwise replace alpha pixels from an image.



-Charles