[whatwg] Adding 2D Canvas features (Was: Grouping in canvas 2d)
wiltzius at chromium.org
Fri Jun 28 12:30:22 PDT 2013
The only major Canvas2D features being actively developed in Chromium right
- 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
> > 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:
> > Adding a parameter to drawImage for sprite sheets to avoid bleeding,
> > proposal from Chrome:
> > Stroke alignment:
> > Page flipping instead of double buffering:
> > Inner shadows:
> > 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