Good thing that we leave Path out of the current 1.0 spec.
Rich Schwerdtfeger
From: Charles Pritchard <chuck@jumis.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
Date: 02/18/2014 03:10 AM
Subject: Re: Fwd: [whatwg] Drawing shapes on canvas
On 2/17/2014 2:58 PM, Rik Cabanier wrote:
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.
Need more info here. "Implemented" v. emulated.
What is your level of accuracy for "correctly".
Is this a rasterization API or a Path API?
A rasterizer could run a simple bitmap xor/and prior to fill, a Path API
would need to, in some possible future, return a path.
We've implemented these before, they're not particular hard, but there are
certainly some issues around precision when it comes to curves.
Glad to have the discussion.
-Charles
