RE: Adding winding rules to Canvas

> What do you think of my proposal to incorporate the winding rule in the path object itself?
> That way, we won't have to update the APIs you listed.

Sorry, I just saw that mail thread.

If the Path object itself specifies the fill rule, then we don't need those additional functions. The downside of the Path object specifying the fill rule is that one cannot reuse an existing path to create two different fills. E.g., I cannot specify the path for a star and then fill with even-odd to get a star without the center filled in, and fill with non-zero to get a star with the center filled in. Though, I think taking advantage of knowing the fill rule for a given path to do background optimizations outweighs that particular downside.

Thanks,
Jatinder

From: Rik Cabanier [mailto:cabanier@gmail.com]
Sent: Tuesday, January 15, 2013 3:14 PM
To: Jatinder Mann
Cc: public-canvas-api@w3.org
Subject: Re: Adding winding rules to Canvas


On Tue, Jan 15, 2013 at 2:59 PM, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:

> As you may know until now, canvas only supported even-odd winding.

> Maybe graphics libraries and SVG also support non-zero winding.

Actually, Canvas 2D Context Level 1 only supports the non-zero winding rule for fill(), clip(), and isPointInPath() today, not even-odd rule.

> 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");



It's great to see a proposal here. I strongly feel we should allow developers to select either non-zero winding rule or even-odd rule, just like other graphics technologies. I prefer this proposal instead of introducing new functions for developers to learn, e.g., eoFill(), eoIsPointInPath(), and eoClip().



I believe we will also need to extend this feature to the following versions of those functions as well:



void fill(Path path, optional CanvasWindingRule w = "nonzero");

void clip(Path path, optional CanvasWindingRule w = "nonzero");

boolean isPointInPath(Path path, unrestricted double x, unrestricted double y, optional CanvasWindingRule w = "nonzero");
Thanks for your feedback Jatinder!

What do you think of my proposal to incorporate the winding rule in the path object itself?
That way, we won't have to update the APIs you listed.

From: Rik Cabanier [mailto:cabanier@gmail.com<mailto:cabanier@gmail.com>]
Sent: Tuesday, January 15, 2013 12:43 PM
To: public-canvas-api@w3.org<mailto:public-canvas-api@w3.org>
Subject: Adding winding rules to Canvas

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