W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] Drawing shapes on canvas

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 13 Jan 2014 14:28:52 -0800
Message-ID: <CAGN7qDDQ3UjgCo8jfWZkucAqUVKi9BN-5+0XmG+Tu-BCKaXo0A@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: Mike Reed <reed@google.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Dongseong Hwang <dongseong.hwang@intel.com>, Jinho Bang <jinho.bang@samsung.com>
On Mon, Jan 13, 2014 at 12:31 PM, Justin Novosad <junov@google.com> wrote:

> Maybe I am missing something, but I think this API could be implemented
> entirely in JS without any new canvas APIs.
>

That is true. Note that this is also true for the current Path proposal


> Do you have a counter example?  Or perhaps you have a use case that would
> be extraordinarily inefficient using current APIs?
>

The issue is that an implementation can use the shape API to optimize for
filled, stroked or unioned shapes ahead of time.
The Path APIs are simply containers of path segments with no drawing
intent. This means that stroking and filling has to be resolved at drawing
time and since those are expensive to resolve, they might impact
performance.


> The way I see it, you would need to use an off-screen canvas to as a
> scratch pad for applying the shape ops (i.e. for compositing paths), but
> wouldn't a native implementation have to do the same?
>

No.
An implementation could use a planarizer (like Skia has) to get a path
that's unionized or do it directly at a low level in the renderer.
For implementation that don't have access to such features, a union could
be done by doing the operations consecutively. (ie a union of a fill and a
stroke shape would be done as a fill followed by a stroke call)




> On Wed, Jan 8, 2014 at 7:55 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> All,
>>
>> around a year ago, I wrote a blog post [1] that introduced a new 'Shape'
>> class that described a filled or stroked region or an area of text. Java2D
>> has a similar concept that they call 'Area' [2].
>>
>> We've had some discussions but it doesn't look like there was any sort of
>> conclusion. I'd like to pick it back up now that we have a partial
>> implementation of the Path object and people are starting to look into
>> extending it.
>>
>> I'll reiterate my proposal:
>> 1. remove all the addxxx methods from the Path2D object [3]
>> Path object are just containers for segments. Aggregating segments will
>> generally not give the desired results since the segments will interact
>> (see [1]).
>> AddPath *could* be kept if people see a strong use case.
>>
>> 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:
>> a. default constructor that creates an empty region
>> b. constructor that take a path and a winding rule. This represents a
>> filled region
>> c. constructor that takes a path, canvasDrawingStyles object and a matrix.
>> This represent a stroked region.
>> d. constructor that takes text + canvasDrawingStyles. This represent a
>> region of filled or stroked text.
>>
>> methods:
>> a. transform -> transform the shape by the matrix and returns a new shape
>> b. add -> add the region of the shape to the current shape and return as a
>> new shape
>>
>> 3. Add new methods:
>> fill(Shape2D)/clip(Shape2D)/isPointInShape(Shape2D,...)
>>
>> 4. remove stroke(path), fill(path), clip(path), isPointInPath(path,...)
>>
>> 5. HitRegionOptions takes a Shape2D instead of a path + winding rule
>>
>> What do people think?
>>
>>
>> 1: http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/
>> 2: http://docs.oracle.com/javase/tutorial/2d/advanced/complexshapes.html
>> 3:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects
>>
>
>
Received on Monday, 13 January 2014 22:29:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC