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

Stephen White senorblanco at chromium.org
Tue Jul 9 08:40:40 PDT 2013


Conversely, if it helps to bring the spec closer to the implementations,
one thing we do not intend to implement in Chrome is the automatic high-DPI
canvas scaling (ie., auto-doubling of backing stores, getImageDataHD(),
putImageDataHD(), etc).

I believe Apple has also announced that they are dropping support for this
in Safari 7.

Stephen



On Fri, Jun 28, 2013 at 3: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