[Webkit-unassigned] [Bug 105508] Proposal: Add webkitFillRule to canvas

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=105508





--- Comment #16 from James Ascroft-Leigh <jwal at jwal.me.uk>  2013-01-02 04:36:28 PST ---
Thanks for the comments about the way this feature is exposed through the canvas API.  I think that a discussion on this topic would be healthy but perhaps this is not the correct forum.  I have just re-raised this proposal on the whatwg mailing list:

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-January/038488.html

Hopefully we will get some more comments from there this time around.

Rik: As for your specific suggestions, clearly the eofill(), eoclip() and eoIsPointInPath() alternative would work.  I don't know how to decide between the two proposals except that one of them is more easily compatible with the Mozilla Firefox prefixed implementation.

As for the argument that the winding rule should not be part of the environment, I disagree that this would be a problem in practice.  Although I am not an expert canvas programmer, my initial impressions are that the API itself is inherently a stateful one.  As long as it is properly included in the state with save() and restore() then any client code wishing to make use of this feature wouldn't be much different for either of these APIs.

On the other hand, the only code I have seen which currently makes use of this in pdf.js might benefit from an eofill() function [1] instead of a fillRule property.  I suspect the reason it was added as a fillRule property in the first place was because this is how Cairo (a rendering backend used by Firefox) exposes the feature.  

How should we choose?

[1] It seems to want an eofill() method: https://github.com/mozilla/pdf.js/blob/1826daa1d522bc17015098e79cee7c6ca8fd3b36/src/canvas.js#L648

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.