- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 18 Feb 2014 01:10:00 -0800
- To: Rik Cabanier <cabanier@gmail.com>
- CC: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
- Message-ID: <53032368.4070801@jumis.com>
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
Received on Tuesday, 18 February 2014 09:10:22 UTC