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

[Rik Cabanier]

Yes, those should be taken out.

On Tue, Jul 9, 2013 at 8:40 AM, Stephen White <senorblanco at 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 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.
>> `._.-(,_..'--(,_..'`-.;.'
>> > >
>> >
>>
>
>