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

[Ian Hickson]

On Thu, 3 Jan 2013, Rik Cabanier wrote:
> >
> > 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.

Implementations of the spec (i.e. 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.

It is? I don't think that's one of the use cases I've seen before. It's an 
interesting use case, though, true.


> 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 [even-odd fill].

The Path objects just store paths, not filled shapes, so you can't really 
store non-zero-based shapes any more than even-odd-based shaped, if you're 
going to mix them.

If this (the region accumulation thing) is a use case we should support, 
then we need a way to add paths together in a way that converts all the 
paths to a specific fill rule type (ideally to be agnostic of the rule).


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

I'd have thought that would make it exactly like the stroke style.


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

I'm happy to defer to the browsers vendors on this -- browser vendosr, 
what would be simpler for you to implement?


> > 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 [even-odd fill].

Could you elaborate on this? How would you propose this should be changed?


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

If you could just file bugs for each mistake, that would be great.

   http://whatwg.org/newbug

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'