- 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