[webkit-dev] Proposal: Add webkitFillRule to canvas

[Rik Cabanier]

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)


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


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


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


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


>
> Greetings,
> Dirk
>
>
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130104/c94fe9f8/attachment.html>