- From: Charles Pritchard <chuck@jumis.com>
- Date: Sun, 16 Feb 2014 14:37:10 -0800
- To: Rik Cabanier <cabanier@gmail.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>
- Message-ID: <53013D96.8050602@jumis.com>
On 1/29/2014 10:49 PM, Rik Cabanier wrote: > I'll reiterate my proposal: ... > 2. introduce a new class 'Shape2D' > Interface: > > [Constructor, > Constructor(Path2D , CanvasWindingRule = "nonzero"), > Constructor(Path2D , CanvasDrawingStyles, SVGMatrix?), // > strokes a path > Constructor(DomString text, CanvasDrawingStyles, > SVGMatrix?, unrestricted double, unrestricted double, boolean > isStroked = false, optional unrestricted double)] > interface Shape2D{ > Shape2D transform(matrix); // returns a transformed path > Shape2D add(Shape2D); // returns a path that is the union of > the 2 paths > } > > This class will represent a painted area. Because it knows the winding > and stroking rules, the browser will be able to do expensive math in > advance. It can also cache the region on the GPU. > constructors: ... > > 1: http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ This proposal is an improvement on the current direction of the Path object. The long-form constructor feels a little tedious/difficult, with 8 arguments to be passed. I'd like to see xor / remove as well, if you're going to have "add" on the Shape2D method. I'd hoped that there would be some discussion between SVG WG, WebGL and Canvas API implementers/consumers prior to messing about with an actual Path API. Has that happened? From what I recall, the Path API was released in a bundle via the WHATWG; there was little transparency in the process. Rik's concerns here do mirror mine: I wanted to check in with other groups to get a better idea as to whether we could better cache paths in the GPU and on typical CPU-based 2D rasterization. Without taking that step, it seems like the introduction of the Path API to Canvas was immature. -Charles
Received on Sunday, 16 February 2014 22:37:34 UTC