[webkit-dev] Proposal: Add webkitFillRule to canvas

[Dirk Schulze]

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.

> 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.

> 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. 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 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.

Greetings,
Dirk


> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev