W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2011

[whatwg] Canvas 2d: proposal to add path(DOMString)

From: Juriy Zaytsev <kangax@gmail.com>
Date: Sun, 31 Jul 2011 21:58:31 -0400
Message-ID: <CAPdhPzmyBMUaj_Cia-PiKcMp48_NJ-czqXfLKV9GmsZTGqzWDQ@mail.gmail.com>
I'd love to see something like this as well.

In my experience this takes more than 80 lines. In Fabric.js [1], for
example, `fabric.Path#render` has ~180 LOC chunk [2] dedicated to doing
exactly this ? drawing translated-from-SVG path using a combination of
`lineTo`, `moveTo`, `bezierCurveTo`, etc. And that's not counting another
~100 lines of arc normalization [3] where arc command is translated to a
sequence of `bezierCurveTo` commands (due to SVG's a/A algorithms being so
different from canvas' `arc` one).

`HTMLRenderingContext::path` seems sufficient since it's always possible to
end it with `fill` or `stroke` (the same way you would do it with
combination of path commands followed by `fill` or `stroke`).

[1] http://kangax.github.com/fabric.js/demos/kitchensink/


On Fri, Jul 29, 2011 at 4:44 PM, Charles Pritchard <chuck at jumis.com> wrote:

> Having spoken to several developers, I think that we're clear to add a new
> method to the canvas 2d api;
> though there is some question about how it should be added.
> The method would take a DOMString using SVG path semantics.
> I'm not certain which route is better:
> ctx.path('M....z')
> or
> ctx.fillPath('M ..z'), ctx.strokePath('M...z');
> This usually takes ~80 lines of JavaScript to support,
> we're eager to see it added to native implementations.
> All browser vendors have SVG support now, and could easily re-use
> code from their SVG implementations to implement this canvas 2d
> supplemental.
> -Charles
Received on Sunday, 31 July 2011 18:58:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:35 UTC