Enable Canvas Path Object

[zoom...@gmail.com]

How do I start working with Canvas Path Objects? I've downloaded Chrome Canary and turned on the experimental Canvas flag at this point. Are there any samples that demo Path Objects?

[mvuj...@adobe.com]

+cc Dirk. He might have some samples on hand.

- Max

[Dirk Schulze]

Hi,

I wrote some lines about the implementation in WebKit and Blink: http://dschulze.com/blog/articles/10/html-canvas-path-object-in-webkit

Greetings,
Dirk

[thomas....@gmail.com]

Thanks for the link, it is dated from Feb so I'm still hoping there might be some more recent reports and samples now. Is there some live proof of concept sample available that runs in a browser? 

When I go to the following page my Chrome or Chrome Canary browser still say that the Path Object feature is not supported:

http://www.rgraph.net/blog/2013/january/html5-canvas-path-objects.html

[PhistucK]

The page only tests for CanvasRenderingContext2D.prototype.addHitRegion for showing the support section. It does not check the Path object, which can actually be instantiated (new Path() works, I did not test its functionality).

This was done using Chrome canary 32.0.1671.3 with the "Enable experimental canvas features" flag enabled.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[RGraph support]

Hi,

That would be "an Oopsy". Fixed now so the page should report it
correctly (from 11pm onwards at least). FWIW I use this page to see
what has been added:

http://kangax.github.io/jstests/canvas-v5/

[thomas....@gmail.com]

Thanks for the link to the canvas tests. Both Chrome Canary and Chrome Version 31.0.1650.16 beta are giving me the same positive result, with the canvas experimental flag enabled. Not sure why Canary is needed then?

[PhistucK]

The canary simply has the latest development. The experimental features that you seek may have already been implemented in some other version, but instead of looking for the exact version, it is easier to just suggest using the canary.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[김동관]

Hello, I am a newbie to blink.

I have a question about run time flag with Path object.

I don't think that Path should be guarded by run time flag because all methods of Path object is implemented by CanvasPathMethods and already exposed by CanvasRenderingContext2D.

So If someone wants to extend API of Path object in the future, they could apply run time flag to extended method only.

I already file a bug at [1] but not sure whether it is right procedure or not.

Do i have to send "Intent to ship" email to Blink-Dev mailing list?

It would be very appreciated if you could give me any guidance for that.

Thank you in advance.

[1] https://code.google.com/p/chromium/issues/detail?id=344707

2013년 10월 16일 수요일 오전 4시 43분 0초 UTC+9, PhistucK 님의 말:

[Jeremy Roman]

This would seem like a non-trivial web-facing change, so per the launch process (http://www.chromium.org/blink#launch-process) it should require an "Intent to Ship". Even if the implementation is simple, exposing it to the open web potentially commits the project to supporting that API in the future.

Looking at the bug for this feature, it doesn't look like people are confident that this is ready to ship yet (or rather, weren't a couple of months ago); have you discussed this with them?

http://crbug.com/159839#c16

[Rik Cabanier]

On Tue, Feb 18, 2014 at 5:51 PM, 김동관 <bp9...@gmail.com> wrote:

Hello, I am a newbie to blink.

I have a question about run time flag with Path object.

I don't think that Path should be guarded by run time flag because all methods of Path object is implemented by CanvasPathMethods and already exposed by CanvasRenderingContext2D.

There's a big difference between having the same methods and introducing a new web-facing object alongside new APIs.

 

So If someone wants to extend API of Path object in the future, they could apply run time flag to extended method only.

I already file a bug at [1] but not sure whether it is right procedure or not.

Do i have to send "Intent to ship" email to Blink-Dev mailing list?

Yes, you should but as Jeremy mentions, 'intent to implement' should come first.

According to http://www.chromium.org/blink#TOC-Exceptions skipping this is only allowed in very rare circumstances.

[TJ]

Where are we at with this Path Object feature by now?

Are we ready to draw yet!

Zoomon

[Rik Cabanier]

I think we're almost good to go.

On the WhatWG, there was a decision to call it Path2D [1] to avoid clashes (ie this change breaks paper.js). It never made it in the spec so implementors didn't know about the name change. :-(

FWIW I have a patch to land the Path2D object in mozilla [2] but didn't have the time to finish it yet.

1: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-November/041456.html

2: https://bugzilla.mozilla.org/show_bug.cgi?id=830734

[Elliott Sprehn]

Yeah we should make the name change and ship this already! :)

[PhistucK]

This sounds so wrong...

Is there a discussion about not exposing new constructors to the global scope anymore?

Although new webAPI.Path() (or anything similar) is longer, it is much safer than introducing more and more names to the global scope which breaks libraries and limits the creativity of the developer and the nomenclature of the objects in an application.

(Though, in this particular case, I would argue that Path is a bit too general even without naming collisions and I would have probably named it CanvasPath)

☆PhistucK

[Dirk Schulze]

On Feb 19, 2014, at 6:05 PM, PhistucK <phis...@gmail.com> wrote:

> This sounds so wrong...
> Is there a discussion about not exposing new constructors to the global scope anymore?
> Although new webAPI.Path() (or anything similar) is longer, it is much safer than introducing more and more names to the global scope which breaks libraries and limits the creativity of the developer and the nomenclature of the objects in an application.
>
> (Though, in this particular case, I would argue that Path is a bit too general even without naming collisions and I would have probably named it CanvasPath)

As pointed out by Rik, the latest name proposal is Path2D instead of Path and most parties agreed to this proposal already. CanvasPath was rejected because the SVG WG wants to make use of this object as well.

Greetings,
Dirk

[PhistucK]

Even though my actual point was somewhat off topic for this thread, that was not my point.

Introducing new constructors to the global scope should be avoided and any built in should be under a platform umbrella of a namespace like webAPI.

☆PhistucK

[Alex Russell]

Why? If it's a generic platform primitive and has low probability of conflict, it seems reasonable to leave it global until such time as ES6 modules save us from the shared-global madness.

[PhistucK]

When will such time come? I reckon we are a few years away.

Meanwhile, the global namespace keeps being polluted with more and more constructors and properties that may or may not collide with global variables or developer created constructors.

And even when ECMAScript 6 modules are available - will you require using ECMAScript 6 (or ECMAScript modules) in order to use the new additions?

☆PhistucK

[Ian Hickson]

On Tue, 18 Feb 2014, Rik Cabanier wrote:
>
> On the WhatWG, there was a decision to call it Path2D [1] to avoid
> clashes (ie this change breaks paper.js). It never made it in the spec
> so implementors didn't know about the name change. :-(

There wasn't a decision, it's just awaiting implementations. Right now
there's one shipping implementation, and it's called the interface Path,
so that's why the spec is still saying Path. It's not a compliant
implementation, so it's not a strong vote, but it's the only vote so far.

This is being tracked here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23918

If an implementation ships a compliant implementation of the API with the
name Path2D, then it would move the balance over and the spec would
change.


> https://bugzilla.mozilla.org/show_bug.cgi?id=830734

Looks like this implementation is also different than the spec (but in a
different way than Apple's). The spec doesn't have a way to change the
"current path"; it instead tries to move people away from the "current
path" concept to just using path objects directly (e.g. calling c.fill(p)
rather than c.setCurrentPath(p); c.fill();). There's been some discussion
of this on the WHATWG list, but I haven't seen any use cases that would
argue for the more complex stateful API rather than the more immediate-
mode style that's currently in the spec.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Alex Russell]

On Wed, Feb 19, 2014 at 12:53 PM, PhistucK <phis...@gmail.com> wrote:

When will such time come? I reckon we are a few years away.

Meanwhile, the global namespace keeps being polluted with more and more constructors and properties that may or may not collide with global variables or developer created constructors.

And even when ECMAScript 6 modules are available - will you require using ECMAScript 6 (or ECMAScript modules) in order to use the new additions?

Most likely.

[Rik Cabanier]

On Wed, Feb 19, 2014 at 1:52 PM, Ian Hickson <i...@hixie.ch> wrote:

On Tue, 18 Feb 2014, Rik Cabanier wrote:
>
> On the WhatWG, there was a decision to call it Path2D [1] to avoid
> clashes (ie this change breaks paper.js). It never made it in the spec
> so implementors didn't know about the name change. :-(

There wasn't a decision, it's just awaiting implementations. Right now
there's one shipping implementation, and it's called the interface Path,
so that's why the spec is still saying Path. It's not a compliant
implementation, so it's not a strong vote, but it's the only vote so far.

This is being tracked here:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=23918

If an implementation ships a compliant implementation of the API with the
name Path2D, then it would move the balance over and the spec would
change.


> https://bugzilla.mozilla.org/show_bug.cgi?id=830734

Looks like this implementation is also different than the spec (but in a
different way than Apple's). The spec doesn't have a way to change the
"current path"; it instead tries to move people away from the "current
path" concept to just using path objects directly (e.g. calling c.fill(p)
rather than c.setCurrentPath(p); c.fill();). There's been some discussion
of this on the WHATWG list, but I haven't seen any use cases that would
argue for the more complex stateful API rather than the more immediate-
mode style that's currently in the spec.

That's stale code in the canvas object that I didn't remove yet. (That's why it's still in progress)

If you look at the idl file, that method is not there: 

https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=830734&attachment=8368633 

I think set/getCurrentPath are useful but it's more important to get this landed.

[PhistucK]

That seems a bit harsh. Would using a module yield a syntax error of some sort in non ECMAScript 6 code? developers must support non ECMAScript 6 browsers.

☆PhistucK

[Dirk Schulze]

If Blink changes the name to Path2D and Firefox lands Path2D, I will either change Path to Path2D in WebKit or make an alias.

I already admitted that the currentPath method as implemented today is not the right way. I will probably remove it. I still think
that something like set/getCurrentPath is more useful. It introduces less complexity in the IDL and implementation.

Greetings,
Dirk

[Rik Cabanier]

On Wed, Feb 19, 2014 at 9:58 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Feb 19, 2014, at 6:05 PM, PhistucK <phis...@gmail.com> wrote:

> This sounds so wrong...
> Is there a discussion about not exposing new constructors to the global scope anymore?
> Although new webAPI.Path() (or anything similar) is longer, it is much safer than introducing more and more names to the global scope which breaks libraries and limits the creativity of the developer and the nomenclature of the objects in an application.
>
> (Though, in this particular case, I would argue that Path is a bit too general even without naming collisions and I would have probably named it CanvasPath)

As pointed out by Rik, the latest name proposal is Path2D instead of Path and most parties agreed to this proposal already. CanvasPath was rejected because the SVG WG wants to make use of this object as well.

I noticed that the path methods have landed, but not the rename to Path2D.

Is someone going to make that change?

[Joe Gregorio]

On Monday, February 24, 2014, Rik Cabanier <caba...@gmail.com> wrote:

On Wed, Feb 19, 2014 at 9:58 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Feb 19, 2014, at 6:05 PM, PhistucK <phis...@gmail.com> wrote:

> This sounds so wrong...
> Is there a discussion about not exposing new constructors to the global scope anymore?
> Although new webAPI.Path() (or anything similar) is longer, it is much safer than introducing more and more names to the global scope which breaks libraries and limits the creativity of the developer and the nomenclature of the objects in an application.
>
> (Though, in this particular case, I would argue that Path is a bit too general even without naming collisions and I would have probably named it CanvasPath)

As pointed out by Rik, the latest name proposal is Path2D instead of Path and most parties agreed to this proposal already. CanvasPath was rejected because the SVG WG wants to make use of this object as well.

I noticed that the path methods have landed, but not the rename to Path2D.

Is someone going to make that change?

 

 

I have a CL in the works for that. Should be ready tomorrow. Will that need a separate Intent to Implement?

  -joe

 

[Elliott Sprehn]

On Mon, Feb 24, 2014 at 5:50 PM, Joe Gregorio <jcgre...@google.com> wrote:

On Monday, February 24, 2014, Rik Cabanier <caba...@gmail.com> wrote:

On Wed, Feb 19, 2014 at 9:58 AM, Dirk Schulze <dsch...@chromium.org> wrote:

On Feb 19, 2014, at 6:05 PM, PhistucK <phis...@gmail.com> wrote:

> This sounds so wrong...
> Is there a discussion about not exposing new constructors to the global scope anymore?
> Although new webAPI.Path() (or anything similar) is longer, it is much safer than introducing more and more names to the global scope which breaks libraries and limits the creativity of the developer and the nomenclature of the objects in an application.
>
> (Though, in this particular case, I would argue that Path is a bit too general even without naming collisions and I would have probably named it CanvasPath)

As pointed out by Rik, the latest name proposal is Path2D instead of Path and most parties agreed to this proposal already. CanvasPath was rejected because the SVG WG wants to make use of this object as well.

I noticed that the path methods have landed, but not the rename to Path2D.

Is someone going to make that change?

 

 

I have a CL in the works for that. Should be ready tomorrow. Will that need a separate Intent to Implement?

Nope. We're not shipping the feature yet so painting the shed a new color is fine.

- E