W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 28 Jun 2013 12:48:47 -0700
Message-ID: <CAGN7qDB3hbZ5o0RDh-E2FkNk3mgoO+5=8E=f_bVa70SsWTEgow@mail.gmail.com>
To: Tom Wiltzius <wiltzius@chromium.org>
Cc: whatwg@whatwg.org, Ian Hickson <ian@hixie.ch>, Brian Salomon <bsalomon@chromium.org>
As long as those features don't build upon other unimplemented features,
there should be no risk.
However, accessibility (=hit regions) is a must and should be tackled as
soon as possible.

Rik

On Fri, Jun 28, 2013 at 12: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 Friday, 28 June 2013 19:49:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC