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

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

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

A region can be a bunch of shapes so I assumed that the path object was
designed to accommodate this.
For instance a stroked rectangle would be a region and consist of a rect
path and the stroked rect path.


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

Exactly! This is my main problem with the path object and why you can't use
it for hit regions.
People (at least me) think of a path as an atomic region that is filled or
stroked. If you combine paths/regions, you expect that the
drawn area is preserved.


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

Yes, strokes and text outlines should be generated so any fill rule can
apply.
I think the spec needs to mention that
- sections of the path where both edges are filled should be removed
- winding needs to be done so eofill and fill give the same result


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

No, usually a bunch of strokes of the same type and color are drawn
consecutively. Not so much with eofill which why it is not part of the
graphics state in almost all graphics libraries.


>
>
> > > > 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.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Friday, 4 January 2013 01:34:02 UTC