[webkit-dev] Proposal: Add webkitFillRule to canvas

[Rik Cabanier]

On Fri, Jan 4, 2013 at 8:04 PM, Dirk Schulze <dschulze at adobe.com> wrote:

>
>
> On Jan 4, 2013, at 7:28 PM, "Rik Cabanier" <cabanier at gmail.com> wrote:
>
>
>
> On Fri, Jan 4, 2013 at 5:42 PM, Dirk Schulze <dschulze at adobe.com> wrote:
>
>>
>> On Jan 4, 2013, at 5:24 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>> >
>> >
>> > On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Fri, 4 Jan 2013, Rik Cabanier wrote:
>> > >
>> > > I think this feature was rushed in the spec.
>> >
>> > The specing is usually the first step. You can't rush to spec. :-)
>> >
>> > In this particular case, though, it was the third or fourth step. The
>> > discussion has been open since June 2011. It's not like people didn't
>> have
>> > time to comment. It's been shipping in a browser for over a year.
>> >
>> > Any solution we come up with to the issues that were raised regarding
>> Path
>> > will almost certainly be done in a way that builds on context.fillRule,
>> > not in a way that removes context.fillRule.
>> >
>> > I was not aware of that discussion.
>> > There are good reasons to make the fill rule part of the fill operation
>> itself. It does not make sense in the graphic state.
>> >
>> > How about EOClip? That is a construct that is far more used than
>> eofill. Will that get its own parameter too?
>>
>> It will use the same property, since there is no difference. That is why
>> the name could be a bit misleading. windingRule would be a bit more
>> independent of the fill operation.
>>
>
> That is a problem. Now you will have to set the parameter before the clip
> and set it back again right after (since you can't use save/restore since
> it blows away the clip)
>
> I don't see the problem here. That is how canvas works currently. fill()
> and clip() use the currentPath. Seems to be more natural to use the
> property then.
>

With the property, you will have to always be sure that it is set to the
value you expect.
So you either set it before every draw or clip, or you only set it before
doing an eoclip or eofill and then set it back.


>
>
>
>>
>> > How about the interaction of stroking and this parameter (if you follow
>> the spec's wording for stroking)?
>>
>> This needs to change as well to match the new behavior. This is more a
>> specification problem and no implementation problem.
>>
>
> I agree. However, user agents didn't have to really think about this
> before but they will have to in the future. Making it part of the state
> will make it much more difficult to implement cleanly.
>
>
> Not at all, as demonstrated with the patch.
>

in the *future*, when for example there is support for paths, this global
flag will make it more difficult. (Paths will need to take winding into
account if we want the regions to be useful)


>
>
>
>>
>> > How about ispointinpath? Will that follow the winding rule in the
>> graphic state?
>>
>> It would depend on the fillRule that you set on the context.
>>
>> > How about hit regions? How can you specify the winding there?
>>
>> This is a good point. But it depends if hit region will be implemented as
>> specified.
>>
>> >
>> > It's better to follow what almost every other graphics library has
>> done: Add an EOFill and an EOClip.
>> > I volunteer to add it to Mozilla if it helps.
>>
>> That is not fully correct. Just Qt and Skia make it explicitly on the
>> Path object (which is not necessarily depending on the fill operation
>> itself). CG does not bundle EOfill with a path, instead you set it during
>> painting. Which is partly as done by the specification, with the exception
>> that it is not part of the graphic state, but also not part of the path
>> logic.
>
>
> Core graphics has indeed no support for paths (just like the current
> canvas implementations)
> However, it does have 'CGContextEOClip' and 'CGContextEOFill' that works
> on the current path which is what I propose we should do.
>
> No, because the path is already applied to the context. That makes the
> property so natural and easy to implement.
>

yes, the current path is in the context, but not the winding rule. That is
specified with 'CGContextEOClip' or 'CGContextEOFill'.
To me, this makes eofill and eoclip a more natural implementation.


>
>
>
>> Cairo graphics has the fill rule as part of the graphic state IIRC.
>>
>> This discussion is a bit misplaced on webkit-dev. Could you continue it
>> on the WHAT WG mailing list please?
>>
>
> I agree. However, if people didn't follow that mailing list, they would
> think that everything is sorted out since Ian emailed this list to say that
> it is in the spec .
>
>
> Right.
>
>
>
>>
>> I would just agree with Rik here, that we should wait a bit more time
>> before implementing it in WebKit. Even if following the Firefox
>> implementation and the needs of PDF.js is a good reason for implementing as
>> suggested by the spec.
>>
>
> If it's for PDF, then a graphic state variable is not the way to go since
> PDF does not have this either.
>
>
> PDF.js - the JavaScript library. Not PDF the standard. And the library
> uses it already according to previous posts.
>

yes, I realize that. That library will be easier to implement if canvas has
the same behavior as PDF.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130104/2e60934e/attachment.html>