[whatwg] CanvasRenderingContext2D with addPath, currentPath

[Rik Cabanier]

On Tue, Nov 5, 2013 at 4:29 AM, Dirk Schulze <dschulze at adobe.com> wrote:

>
> On Nov 5, 2013, at 5:22 AM, Rik Cabanier <cabanier at gmail.com> wrote:
>
> > On Mon, Nov 4, 2013 at 7:29 PM, Rik Cabanier <cabanier at gmail.com> wrote:
> >
> >>
> >>
> >> On Mon, Nov 4, 2013 at 5:21 PM, Robert O'Callahan <robert at ocallahan.org
> >wrote:
> >>
> >>> If you return a path in user-space, what do you get if you call
> >>> getCurrentPath with a singular transform?
> >>>  ctx.moveTo(0,0);
> >>>  ctx.lineTo(1,1);
> >>>  ctx.scale(0,0);
> >>>  var p = ctx.getCurrentPath();
> >>>
> >>
> >> I mixed up my terms :-)
> >> getCurrentPath should return the path in device coordinates (not user).
> >>
> >> However, for your example, I'm unsure what the right solution is. The
> >> canvas specification is silent on what the behavior is for
> non-invertible
> >> matrices.
> >> I think setting scale(0,0) or another matrix operation that is not
> >> reversible, should remove drawing operations from the state because:
> >> - how would you stroke with such a matrix?
> >> - how do patterns operate? the same for gradient fills.
> >> - how would you pass this to the underlying graphics library?
> >> - certain operators such as 'arc' rely on doing the transform in
> reverse.
> >>
> >> I seem to remember that for SVG we decided that non-invertible matrices
> >> don't draw either.
> >>
> >
> > After pondering this some more and looking at the different
> > implementations, I propose the following:
> > if the user sets a non-invertible matrix, the canvas context should be
> in a
> > state that ignores all path drawing operations, stroke/fill calls and all
> > other ctm operations (apart from setTransform). setCurrentPath is also
> > ignored and getCurrentPath should return an empty path.
> > If the ctm becomes invertible again (from a setTransform or a restore),
> > drawing operations pick up again with the currentPoint that was active
> when
> > the non-invertible matrix was set.
>
> This is not the behavior of current browsers as discussed in a different
> threat about non-invertible CTMs. Firefox seems to add new path segments to
> the coordinate origin. The behavior of WebKit is a bit different and
> depends how the matrix got not-invertable.


Yes, I was looking at the WebKit implementation since it looked the most
sensible.
I'm unsure why you say "how the matrix got not-invertable". There are
checks all over the code to skip if the CTM is non-invertible, ie:

void CanvasPathMethods::moveTo(float x, float y){

...

if (!hasInvertibleTransform())

return;



> I am supportive for clear rules at this point. Ian’s response so far was
> that it doesn’t need any further definition. That is why no implementation
> changed the behavior since then.


Is this the link:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-January/038798.html
I don't see any replies...
You had an error in one of your examples which probably why you thought
there was still drawing after scale(0,0), here are updated links:

http://jsfiddle.net/Dghuh/5/
http://jsfiddle.net/Dghuh/6/



> >
> > I could be convinced that set/getCurrentPath should still work...
> >
> > so If I expand your example a bit:
> >
> > ctx.moveTo(0,0);
> > ctx.lineTo(1,1);
> > ctx.scale(0,0);
> > var p = ctx.getCurrentPath(); // return empty path
> >
> > ctx.stroke(); // nothing happens
> >
> > ctx.setTransform(1,0,0,1,0,0);
> > p = ctx.getCurrentPath(); // return path with moveto/lineto
> > ctx.stroke(); // draw line
> >
> >
> > This would match what WebKit and Blink are doing.
> > Firefox gets in a bad state as soon as you set a non-invertible matrix
> but
> > we could fix that ;-)
>
> Again, the behavior is different depending on how you got to the
> not-invertible CTM, which is obviously not great. I would be supportive of
> not adding any path segments unless the CTM is invertible.
>
> > IE keeps drawing and even strokes when scale(0,0) is set.
> >
> > It would be nice to have interop…
>
> Yes!
>
> Greetings,
> Dirk
>
>