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

Re: [whatwg] CanvasRenderingContext2D with addPath, currentPath

From: Rik Cabanier <cabanier@gmail.com>
Date: Fri, 1 Nov 2013 20:50:42 -0700
Message-ID: <CAGN7qDAywniESHfaVWMMzdrn04w-r6DpkJ4DMOS1Ho2=_vpENw@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
On Fri, Nov 1, 2013 at 7:22 PM, Ian Hickson <ian@hixie.ch> wrote:

>
> (Please don't cross-post to the WHATWG list and other lists, as it causes
> thread fragmentation when people not on the WHATWG list respond.)
>
> On Fri, 1 Nov 2013, Rik Cabanier wrote:
> >
> > The latest Safari is shipping currentPath and Blink has implemented it
> > behind a runtime flag.
> > Could we put this in the specification?
>
> What's the use case?
>

It would be a very fast way to set a cached path in the graphics state.
There's no need to apply the current transform and the underlying path
object can quickly be copied since it replaces the current path (as opposed
to adding to it)


>
> I intentionally didn't add this to the spec when I was adding the last set
> of path-related features, because it seems entirely redundant with Path
> objects. I thought we'd want people to move away from using the implicit
> path, rather than making it more powerful.


The intent is to move away from path to describe filled or stroked regions.


> > the proposal is for a new attribute on the 2d canvas rendering context:
> >
> > attribute Path currentPath;
> >
> > This attribute would give you a non-live/copy of the current path in
> device
> > space.
>
> If it returns a copy, it should be a method.


That's a problem :-(
Shipping Safari has an attribute and it duplicates the path when ask for
the current path.
Received on Saturday, 2 November 2013 03:51:08 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:13 UTC