[whatwg] <canvas> shadow feedback

[Ian Hickson]

On Wed, 29 Apr 2009, Charles Pritchard wrote:
> 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?

Given that it requires shadows to be supported, it seems odd to also have 
requirements for what happens if they're not supported. It also seems 
unlikely that anyone would follow such requirements, since they're already 
not following the other requirements.


> > 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?

Oops, fixed.



> 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.

It's in section 4.8.11.1.12 Drawing model.


> Do shadows work with drawImage / CanvasPattern ?

The spec says "Images are painted without affecting the current path, and 
are subject to shadow effects, global alpha, the clipping region, and 
global composition operators". I'm not sure how they would affect 
CanvasPattern though.


> > I've added a "v2" note in the spec suggesting this.
>   
> Did this note go anywhere?

v2 notes are in the spec source in comments.


> 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
> }

I'm not really sure what problems these proposals are trying to solve. In 
any case, v2 is probably some way away at this point.


> > 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.

Which vendors are having difficulty implementing HTML5 because of the 
shadows?


> 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.

I assure you that they are not 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.

We will probably add this in a future version, yes. If you look in the 
source you'll find a number of proposals marked "v2" that are scheduled 
for a future version of this API.


> With shadow support already enabled in a project, it would take minimal 
> effort to support two additional filters.

There are literally dozens of features that would take little effort -- 
but they would take effort away from other parts of HTML5.


> 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.

Yes, but what other part of HTML5 would you drop instead? Browser vendors 
only have a finite number of resources to spread across the entire Web 
platform.

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