- From: Juriy Zaytsev <kangax@gmail.com>
- Date: Sun, 31 Jul 2011 21:58:31 -0400
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/ [2] https://github.com/kangax/fabric.js/blob/gh-pages/src/path.class.js#L247-433 [3] https://github.com/kangax/fabric.js/blob/gh-pages/src/path.class.js#L17-121 -- kangax 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