W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2013

Re: Adding winding rules to Canvas

From: Simon Sarris <simon.sarris@gmail.com>
Date: Tue, 15 Jan 2013 16:23:01 -0500
Message-ID: <CAA5isUYpFXJm=96gEUD7RsrcaGRUYGHv7kz8nRdOkgzXVcvA-g@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: public-canvas-api@w3.org
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 <cabanier@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
>
Received on Tuesday, 15 January 2013 21:23:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 15 January 2013 21:23:30 GMT