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

Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with "nonzero" (default) and "evenodd" options

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 9 Jan 2013 16:06:49 -0800
Message-ID: <CAGN7qDCoKD5Y=W1sSUURncDjoPb=bBXsG0ceYpWxC_TDcjfwVg@mail.gmail.com>
To: James Ascroft-Leigh <jwal@jwal.me.uk>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Chris Jones <cjones@mozilla.com>, Dirk Schulze <dschulze@adobe.com>, Dean Jackson <dino@apple.com>, Ian Hickson <ian@hixie.ch>
On Wed, Jan 9, 2013 at 3:56 PM, James Ascroft-Leigh <jwal@jwal.me.uk> wrote:

> Hi,
>
> Thanks Rik for your counter proposal and thanks everyone for helping to
> refine it.  I am in full agreement that an evenodd or nonzero argument to
> the fill() and clip() operations is better than a state property.  The only
> thing I can think of in favor of the fillRule property that prompted this
> discussion is for client code to discover whether the feature is
> implemented.
>
> pdf.js seems like a great example of a need for this.  They are going to
> need to check whether the fill() operation supports setting the winding
> rule and fall back to the mozFillRule property if not.  Some website might
> need to detect that neither feature is present and fall back to server-side
> rendering.
>
> How can the presence of the winding rule parameter of the fill() and
> clip() operations be detected by client code?  Perhaps I missed something
> in the discussion.
>

We did not discuss it. You can use 'isPointInPath' with the 'evenOdd'
parameter to see if it's being honored.


>
> Regards,
>
> James
>
> P.S. Looks like I might not get my first patch into WebKit as I had hoped.
> I am still happy to help out coding some of this and writing up test cases
> so please let me know if there is something you think I can contribute.
>

Do you want to take over my patch?


>
>
> On 9 January 2013 21:20, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> Thanks for your feedback!
>> Based on this, I propose the following:
>> 1. create an enum for the winding rule:
>>
>> enum CanvasWindingRule { "nonzero
>> <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
>> >",
>> "evenodd <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-evenodd
>> >"
>>
>> };
>>
>> Since this enum will likely be used by the path syntax (and possibly SVG),
>> maybe we can leave the 'Canvas' portion off
>> 2. extend fill:
>>
>> void fill <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fill
>> >(optional
>> CanvasWindingRule w = "nonzero
>> <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
>> >");
>>
>> 3. extend clip:
>>
>> void c <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fill
>> >lip(optional
>> CanvasWindingRule w = "nonzero
>> <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
>> >");
>>
>>
>> 4. extend isPointInPath:
>>
>> boolean isPointInPath
>> <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-ispointinpath
>> >(unrestricted
>>
>> double x, unrestricted double y, optional CanvasWindingRule w =
>> "nonzero <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
>> >");
>>
>>
>>
>> Rik
>>
>> On Wed, Jan 9, 2013 at 11:59 AM, Tab Atkins Jr. <jackalmage@gmail.com
>> >wrote:
>>
>> > On Wed, Jan 9, 2013 at 11:42 AM, Rik Cabanier <cabanier@gmail.com>
>> wrote:
>> > > Do people have an opinion on a boolean value vs an enum?
>> > > A boolean value is slightly faster to execute and type while an enum
>> is
>> > > more descriptive.
>> > >
>> > > So far, canvas has not used enum values before.
>> >
>> > I strongly prefer enums for cases where it's not a simple yes/no, and
>> > this clearly qualifies.
>> >
>> > (I also prefer enums generally even when this is true, but that's my
>> > CSS experience talking, where we have a history of changing things
>> > that were once booleans into multi-state when people ask for more
>> > features later.)
>> >
>> > ~TJ
>> >
>>
>
>
Received on Thursday, 10 January 2013 00:07:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT