On Mar 18, 2014, at 10:38 AM, Jürg Lehni <[email protected]> wrote:
> So is currentPath going away then for sure? Will there still be a way to to > retrieve a Path2D representation of the path being drawn by the long existing > drawing commands on the context? > > I quite liked how I could use it for caching, in case the browser supported > that feature, and check wether I have a cached path the next time I need to > draw it, falling back on redrawing it using the same drawing commands. Doing > the same by feature-detecting the Path(2D) constructor and building separate > drawing approaches based on its existence results in much more complicated > code. I am still in favor for a setter and getter as well. It had the benefit that you were able to transform the context and it affected drawing commands as well. It is more complicated to create a second Path2D object and add it to a previous path with a transform. I have to admit that the currentPath attribute implemented in WebKit was a mistake though. It created copies instead of references. It seems that Blink and Firefox are more willing to follow the current spec. Therefore, I added Path2D as argument for fill, stroke and clip in WebKit. currentPath was removed and Path renamed to Path2D. Greetings, Dirk > > J > > On Mar 14, 2014, at 23:18 , Rik Cabanier <[email protected]> wrote: > >> >> >> >> On Wed, Dec 4, 2013 at 5:18 PM, Rik Cabanier <[email protected]> wrote: >> >> >> >> On Wed, Dec 4, 2013 at 11:10 AM, Jürg Lehni <[email protected]> wrote: >> I somehow managed to oversee all the things that happened in this >> discussion, but I'm very happy to see that Path2D is being proposed and >> agreed on now. It's also what I've originally suggested on April 10 this >> year, and I completely agree that it leaves much less doubt about its >> functionality and context of use. It also has a history as a term in Java2D: >> >> http://docs.oracle.com/javase/7/docs/api/java/awt/geom/Path2D.html >> >> So is this going through? >> >> Yes, all that need to happen is for someone to implement this :-) >> >> Path2D has now landed in Blink [1]. Blink also implemented the 'addPath' >> method. >> WebKit just landed a patch to rename Path to Path2D, remove currentPath and >> add fill/stroke/clip with a path [2]. >> A patch is under review for Firefox to add Path2D. >> >> Given this, can we change the spec to reflect the new name? >> >> 1: https://codereview.chromium.org/178673002/ >> 2: https://webkit.org/b/130236 >> 3: https://bugzilla.mozilla.org/show_bug.cgi?id=830734 >> >> >> On Nov 18, 2013, at 19:03 , Elliott Sprehn <[email protected]> wrote: >> >>> On Monday, November 18, 2013, Rik Cabanier wrote: >>> >>>> >>>> >>>> >>>> On Wed, Nov 13, 2013 at 1:36 PM, Robert O'Callahan >>>> <[email protected]<javascript:_e({}, 'cvml', '[email protected]');> >>>>> wrote: >>>> >>>>> On Wed, Nov 13, 2013 at 12:12 PM, Jussi Kalliokoski < >>>>> [email protected] <javascript:_e({}, 'cvml', >>>>> '[email protected]');>> wrote: >>>>> >>>>>> Path is also too generic even in the context of graphics. If we later on >>>>>> want to add a path object for 3-dimensional paths, you end up with Path >>>>>> and >>>>>> Path3D? Yay for consistency. Path2D would immediately inform what >>>>>> dimensions we're dealing with and also that this is to do with graphics, >>>>>> and thus sounds like a good name to me. >>>>>> >>>>> >>>>> Sounds good to me. >>>>> >>>> >>>> Elliot, >>>> >>>> what do you think, is Path2D acceptable? >>>> >>> >>> Sounds great to me, lets do it! >>> >>> - E >> >> >> >
