[whatwg] CanvasRenderingContext2D with addPath, currentPath

[Dirk Schulze]

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


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