- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 9 Jul 2013 08:41:47 -0700
- To: Stephen White <senorblanco@chromium.org>
- Cc: Tom Wiltzius <wiltzius@chromium.org>, WHAT Working Group <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Brian Salomon <bsalomon@chromium.org>
Yes, those should be taken out. On Tue, Jul 9, 2013 at 8:40 AM, Stephen White <senorblanco@chromium.org>wrote: > 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:42:12 UTC