- From: Stephen White <senorblanco@chromium.org>
- Date: Tue, 9 Jul 2013 11:40:40 -0400
- To: Tom Wiltzius <wiltzius@chromium.org>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Rik Cabanier <cabanier@gmail.com>, Brian Salomon <bsalomon@chromium.org>
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@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@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@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. > `._.-(,_..'--(,_..'`-.;.' > > > > > >
Received on Tuesday, 9 July 2013 15:41:05 UTC