Re: Fwd: [whatwg] Drawing shapes on canvas

On Sun, Feb 16, 2014 at 2:37 PM, Charles Pritchard <chuck@jumis.com> wrote:

>  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.
>

Yes.
I left it out since those operators aren't easily emulated.
If we had access to an open source library that could calculate this
correctly and in an efficient way, it can be added again.

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.
>

I don't think so. The SVG WG wants to adopt the path object but they mostly
want it as a container for the "d" attributes.
I emailed the WebGL mailing if they would be interested in shapes, but got
not reply.

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.
>

We got feedback from the skia folks who believed that caching on the GPU
would definitely help but they didn't want to hold up the spec over it.