[whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)

Benoit Jacob jacob.benoit.1 at gmail.com
Fri Jun 28 19:01:01 PDT 2013 

Has the Canvas 2D community considered a WebGL-like model to the
introduction of additional features?

By "the WebGL model", I mean:
- Define a core feature set that's conservative and limited, but
consistently implemented by all browsers. Enforce consistent support for it
by an exhaustive conformance test suite.
- Let any additional feature be an "extension". Using the feature requires
first explicitly calling context.getExtension("featurename"); . This helps
ensuring that Web pages don't accidentally rely on that feature, and
instead, make a conscious portability-vs-features trade-off.
- Consider, similar to WebGL, further tightening this process by letting
any new feature start at "draft" status and wait a bit before being
"approved".  Typically, the difference that this makes is that "draft"
extensions would be exposed by browsers only "behind  a flag" (a browser
option that's not enabled by default). Prerequisites for "approval" would
include: having been implemented and stable for some time, and being
covered by a conformance test.

If there is any doubt that such a model can be useful in practice, WebGL
has been very successful so far at combining fast feature iteration with
tight cross-browser compatibility, using a similar model.

See this document:
  http://www.khronos.org/registry/webgl/extensions/
.,. except it needs updating to reflect the recent move away from vendor
prefixes to flags, by some major browsers.

Benoit


2013/6/28 Tom Wiltzius <wiltzius at chromium.org>

> I agree there isn't a risk of these unrelated additional features not
> matching their hypothetical specs.
>
> However, my concern is Ian's comment that he'd prefer not to add additional
> features to the spec -- some of the ones being actively developed in
> Chromium aren't added yet, and I'd hate for them to not get added even if
> we have consensus on their behavior and early implementations.
>
> To quote Ian's initial message:
>
> """I think before we add more features, it's important that we figure out
> which browsers want to implement which features, and that we start with
> the highest priority ones.""""
>
> ... so I'm trying to provide context about what Chromium is currently
> implementing, and hence what might be higher priority to spec.
>
>
> On Fri, Jun 28, 2013 at 12:48 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
> > As long as those features don't build upon other unimplemented features,
> > there should be no risk.
> > However, accessibility (=hit regions) is a must and should be tackled as
> > soon as possible.
> >
> > Rik
> >
> >
> > On Fri, Jun 28, 2013 at 12:30 PM, Tom Wiltzius <wiltzius at chromium.org
> >wrote:
> >
> >> The only major Canvas2D features being actively developed in Chromium
> >> right now are:
> >>
> >>  - having a canvas context "alpha" attribute
> >>  - text decoration
> >>  - compositing and blending
> >>  - canvas access in workers
> >>
> >> (easily referenced from http://www.chromestatus.com/features)
> >>
> >> It is concerning to me that the list of other unimplemented features
> that
> >> aren't being worked on could block the standardization of the above
> (all of
> >> which have been discussed on this list at one point, but not all of
> which
> >> are in the spec yet).
> >>
> >> How can we help reconcile this discrepancy?
> >>
> >>
> >> On Fri, Jun 14, 2013 at 11:54 AM, Rik Cabanier <cabanier at gmail.com
> >wrote:
> >>
> >>> I agree that hit regions should be high on the priority list. They've
> >>> been
> >>> in the spec for a while and are absolutely required for accessibility.
> >>> I will try to follow up on this feature with the browsers. We recently
> >>> added a basic Path object to WebKit and I know that mozilla is looking
> at
> >>> the path object.
> >>>
> >>> At this point, I wouldn't ask to add begin/endLayer to the spec.
> Instead,
> >>> we will talk to the browser vendors and work on implementing the
> feature.
> >>> Just putting it in the spec is not enough to get an implementation...
> >>>
> >>> On Fri, Jun 14, 2013 at 10:42 AM, Ian Hickson <ian at hixie.ch> wrote:
> >>>
> >>> > On Fri, 14 Jun 2013, Brian Salomon wrote:
> >>> > >
> >>> > > As an implementor, we would prefer the layer approach. This would
> >>> have
> >>> > > lower overhead in Chromium/Skia. We can make better decisions about
> >>> > > caching and deferred rendering. It also seems like a really handy
> API
> >>> > > for devs, especially the ability to inherit the graphics state.
> Would
> >>> > > the spec have anything to say about beginLayer()/endLayer()
> >>> balancing,
> >>> > > especially with respect to RAF?
> >>> >
> >>> > I have no ojection to adding this to the spec, but right now the spec
> >>> has
> >>> > a bunch of features that aren't implemented, and there's a long list
> of
> >>> > other features people want that aren't yet specced. I'm very hesitant
> >>> to
> >>> > get the spec further and further away from implementations.
> >>> >
> >>> > For example, here are some of the bug numbers for <canvas> feature
> >>> > requests:
> >>> >
> >>> > 11399   <canvas> Locking individual color channels (e.g. drawing to
> >>> alpha
> >>> >                  only)
> >>> > 21835   <canvas> Path object should have a way to add paths keeping
> >>> only
> >>> >                  the union given a fill rule
> >>> > 21939   <canvas> Path objects would be much more useful if their
> >>> >                  individual commands (moveTo, lineTo, etc.) could be
> >>> >                  inspected from JavaScript [...]
> >>> > 8794    <canvas> lineWidth = 'hairline'
> >>> > 11739   <canvas> clearPath() that clears pixels the way clearRect()
> >>> does,
> >>> >                  but using a path
> >>> > 9236    <canvas> Detecting the intersection of Path objects
> >>> > 9235    <canvas> perspective transformations
> >>> > 18751   <canvas> a way to get the coordinate of the last point in a
> >>> path
> >>> > 21346   <canvas> Have ImageBitmap expose height and width attributes
> >>> >
> >>> > (Bugs accessible from https://www.w3.org/Bugs/Public/)
> >>> >
> >>> > There's also the printCallback API proposal from Mozilla:
> >>> >
> >>>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0371.html
> >>> >
> >>> > Adding a parameter to drawImage for sprite sheets to avoid bleeding,
> >>> > proposal from Chrome:
> >>> >
> >>>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0088.html
> >>> >
> >>> > Stroke alignment:
> >>> >
> >>>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Jul/0238.html
> >>> >
> >>> > Page flipping instead of double buffering:
> >>> >
> >>>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0073.html
> >>> >
> >>> > Inner shadows:
> >>> >
> >>> >
> >>>
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/038079.html
> >>> >
> >>> >
> >>> > Plus, as I mentioned, things in the spec that aren't implemented
> >>> widely:
> >>> > Right now, the things in the spec that aren't widely implemented are
> >>> the
> >>> > things that were needed for accessibility (hit regions) and the
> things
> >>> > that are the basis for some of the most-requested features (Paths).
> >>> >
> >>> >
> >>> > I think before we add more features, it's important that we figure
> out
> >>> > which browsers want to implement which features, and that we start
> with
> >>> > the highest priority ones.
> >>> >
> >>> > --
> >>> > Ian Hickson               U+1047E                )\._.,--....,'``.
> >>>  fL
> >>> > http://ln.hixie.ch/       U+263A                /,   _.. \   _\
>  ;`._
> >>> ,.
> >>> > Things that are impossible just take longer.
> >>> `._.-(,_..'--(,_..'`-.;.'
> >>> >
> >>>
> >>
> >>
> >
>

More information about the whatwg mailing list