Re: Fwd: [whatwg] Drawing shapes on canvas

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