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

[Rik Cabanier]

On Thu, Jan 3, 2013 at 3:38 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 10 Jun 2011, Chris Jones wrote:
> >
> > In 2D canvas, determining whether a point is "inside" a path is
> > currently always done using the non-zero winding rule.  I propose
> > extending 2D canvas to allow determining inside-ness using the even-odd
> > rule.
>
> I've added this to the spec.
>
>
> On Wed, 2 Jan 2013, Dirk Schulze wrote:
> >
> > There was a complain on the webkit bug report if fillRule should be part
> > of the graphics state or not. Did you investigate what current 2d
> > graphics libraries do (qt, Cairo, CG, ...)? Is it part of the graphics
> > state there?
>
> I have made it be part of the graphics state in the spec; it would be
> unusual in the API for it not to be. However, if this doesn't match
> implementations, please let me know.
>

Do you mean browser implementations or graphic libraries?
AFAIK all graphic libraries except cairo are different.
I'm unsure about the browsers.


>
>
> On Wed, 2 Jan 2013, Rik Cabanier wrote:
> >
> > this features is not a trivial as it seems. Adding this will necessitate
> > updates to the algorithms that deal with paths and the outlining of
> > strokes and text.
>
> Can you elaborate on what updates are needed? I couldn't see any that
> actually needed to be changed.
>

One of the intents of the path object is so you can 'accumulate' the
regions that were drawn so you can set them up as hit regions.
This means that a hit regions can contain shapes that were drawn with
different winding rules. The current path syntax does not allow you to
store this information so you can't set up a hit region that was drawn with
an eofill.


> > As Dirk mentioned, instead of making it part of the graphics state, it's
> > more likely better to make it part of the fill or clip operator like
> > SVG, PDF and PostScript.
>
> That seems like it would be inconsistent with the rest of the canvas API.
>

Winding is specific per draw and unlikely to persist across several draw
commands. This makes it different than color or the stroke style.


>
>
> > In addition, the path object will need to be extended so it can deal
> > with this idiom.
>
> Can you elaborate on how this affects the Path object? It seems like it
> would be somewhat orthogonal.
>

See above


>
>
> > The easiest way to implement this, would be to leave the core interface
> of
> > canvas alone and just extend the path object with winding rules and a
> > method to 'simplify' a path so it can be drawn with any winding rule.
>
> This doesn't seem like it would be easier... in particular, fillRule is
> now implemented in two browsers, so the implementation cost for them would
> be zero, and they don't yet implement Path at all, so the implementation
> cost for Path would be quite high, even without "simplify". :-)
>

It's easier because of all the other work that's necessary to make this
feature work correctly.
So, yes, it is easier now because they don't rely on the spec to implement
stroking and they don't have an implementation for paths.

However, the spec is supposed to be followed (right?) and at some point,
paths should be implemented. Going the easy way now will give a headache
later.


> On Wed, 2 Jan 2013, Rik Cabanier wrote:
> >
> > However, just look at how stroke is implemented in the Canvas 2d spec or
> > how you can create paths by stroking or stroked text. They're all
> > affected by the winding rules.
>
> How so?
>

For instance, take a figure eight that is stroked.
If you draw it out, you will see that you cross 2 lines to get to the
middle which means that there will be a gap when doing an eofill.


>
>
> > (The description on how to do strokes in the spec is very wrong, but
> > that can be addressed later)
>
> Can you elaborate on this? If there's a mistake obviously I'd like to fix
> it...
>

I'm unsure where to begin...
Note that the issue with EOFill will also happen with regular fills of
intersecting paths and NZO filling. Part of the stroking process is to
remove path segments that have a fill on both sides.

Maybe the spec should say how you do strokes but instead show the results
of the different parameters.


>
>
> > Dirk and I did a bit more research and found that SVG, PDF, Flash,
> > PostScript, Skia, Core Graphics and Direct2D all have the winding rules
> > as part of the fill operator. It seems strange that canvas would choose
> > to have a different interface...
>
> People using the canvas API are more likely to know the canvas API, and
> thus want extensions to be consistent with the canvas API, than they are
> to be familiar with PDF, Flash, PostScript, Skia, Core Graphics, or
> Direct2D. Incidentally, of those, I'm only familiar with SVG, and SVG is
> similar to what I specced (indeed I don't see how it could be part of the
> operator since it's a declarative language).


In SVG everything is part of the fill operator since it doesn't rely on
state (except for 'inherit')