All,
so after talking to Dirk, maybe it's better to rename the classes so Path
is the one that has the geometry and StyledPath contains the region.
Prototype IDL:
[Constructor,
Constructor(path), // creates a copy
Constructor(DOMString)] //takes SVG path syntax
interface Path {
};
Path implements CanvasPathMethods;
[Constructor,
Constructor(Path, CanvasWindingRule = "nonzero"), // creates a copy of path
Constructor(DomString text, CanvasDrawingSTyles, SVGMatrix?, unrestricted
double , unrestricted double , optional unrestricted double)]
interface StyledPath {
StyledPath Transform(matrix); // returns a transformed path
StyledPath Stroke(CanvasDrawingStyles); // returns a stroked path
StyledPath Add(StyledPath); // returns a path that is the union of the 2
paths
boolean isPointInPath(unrestricted double x, unrestricted double y);
};
interface CanvasRenderingContext2D {
....
void Fill(StyledPath);
}
dictionary HitRegionOptions {
StyledPath? path = null;
....
}
Any comments?
On Tue, Jan 15, 2013 at 1:49 PM, Rik Cabanier <caban...@gmail.com> wrote:
> Hi Simon,
>
> I completely agree with you.
> As specified today, hit regions don't have support for winding. In fact,
> it is even worse: if you have a set of drawing commands, you can't get
> their region.
> The reason for this is that the path object (as currently defined) simply
> accumulates path segments. This will wreak havoc with shapes that touch or
> that have strokes.
>
> I have stated this a couple of times already on whatwg...
> What I would like to see is more like this:
>
> class PathSink implements CanvasPathMethods {
> PathSink();
> PathSink(DOMString); //takes SVG path syntax
> }
>
> class Path {
> Path();
> Path(PathSink, CanvasWindingRule = "nonzero");
> Path(DomString text, CanvasDrawingSTyles...); // to get text outline
>
> Path Transform(matrix Transformation);
> Path Stroke(...);
>
> Path Add(Path); // <----
> }
>
>
> The 'Add' method would not simply aggregate path segments. Instead, the
> area of resulting path will be a union.
>
> So, for example, if you want to create a region with a stroke rectangle:
>
> var h = new PathSink();
> h.rect(100, 100, 200, 200);
> var P = new Path(h);
> P = P.Add(P.Stroke({'lineWidth': 10}));
>
>
>
> On Tue, Jan 15, 2013 at 1:23 PM, Simon Sarris <simon.sar...@gmail.com>wrote:
>
>> Before we comment on your proposal I have some notes I'd like to share
>> because the current *fillRule *rules in the specification seem
>> incomplete or at least ill-defined.
>>
>> The new hit regions use a *Path* in the *HitRegionOptions* (the argument
>> to *addHitRegion*) in order to function, but its not clear what fill
>> rule these *Path* objects are using for hit-testing. Even-odd and
>> winding fill rules create different holes in a path, so it matters a good
>> deal for hit testing.
>>
>> There seem to be three possibilities as implemented:
>>
>> 1. HitRegions only ever use winding paths. This seems like a bad idea.
>> 2. Whichever *fillRule* is defined when *context.addHitRegion* is
>> called determines the *fillRule *for that hit region's *Path *permanently.
>> This seems acceptable but confusing and should be clarified if it is
>> currently the case.
>> 3. The fillRule of a hit region changes dynamically as *
>> context.fillRule* changes. This would be a nightmare.
>>
>>
>> I hope it is #2, but the specification makes no mention of this.
>>
>> Actually, I'd prefer that either *HitRegionOptions *or the *Path *object
>> would need to have a *fillRule *attribute.
>>
>> If the specification does adopt something similar to Cabanier's
>> suggestions then that would need to be done anyway.
>>
>> In short, if *isPointInPath *is changed to specify *fillRule*, *
>> HitRegionOptions* (the argument to *addHitRegion*) or the *Path* given
>> in the options needs to change too.
>>
>>
>> Simon Sarris
>>
>>
>> On Tue, Jan 15, 2013 at 3:42 PM, Rik Cabanier <caban...@gmail.com> wrote:
>>
>>> All,
>>>
>>> there was a recent discussion on adding winding rules to canvas. As you
>>> may know until now, canvas only supported even-odd winding.
>>> Maybe graphics libraries and SVG also support non-zero winding.[1][2]
>>>
>>> Mozilla exposes this currently with 'mozFillRule'. Making this part of
>>> the graphics state has several drawbacks.
>>> The biggest is that fill/clip will now have to check the state every
>>> time, or set/reset it. Winding is also part of path geometry.
>>>
>>> I have the following proposal:
>>>
>>> enum CanvasWindingRule { "nonzero", "evenodd" };
>>> void fill(optional CanvasWindingRule w = "nonzero");
>>> void clip(optional CanvasWindingRule w = "nonzero");
>>> boolean isPointInPath(unrestricted double x, unrestricted double y,
>>> optional CanvasWindingRule w = "nonzero");
>>>
>>>
>>> proposed patches for this API can be found here:
>>> https://bugs.webkit.org/show_bug.cgi?id=105508
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=827053
>>>
>>> What do people think?
>>>
>>> 1: http://www.w3.org/TR/SVG/painting.html#FillRuleProperty
>>> 2: http://en.wikipedia.org/wiki/Nonzero-rule
>>>
>>
>>
>
