[whatwg] CanvasRenderingContext2D with addPath, currentPath

[Dirk Schulze]

On Nov 5, 2013, at 6:56 PM, Rik Cabanier <cabanier at gmail.com<mailto:cabanier at gmail.com>> wrote:




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

On Nov 5, 2013, at 5:22 AM, Rik Cabanier <cabanier at gmail.com<mailto:cabanier at gmail.com>> wrote:

> On Mon, Nov 4, 2013 at 7:29 PM, Rik Cabanier <cabanier at gmail.com<mailto:cabanier at gmail.com>> wrote:
>
>>
>>
>> On Mon, Nov 4, 2013 at 5:21 PM, Robert O'Callahan <robert at ocallahan.org<mailto: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 need to check the code again, it might be a mistake in the examples. I was wondering about the mistake. Yes, WebKit has a lot of checks in the code to avoid drawing (helped to add them :)).

Reply to my original post was on July 18 :) so you need to look a bit further into the future :P

Greetings,
Dirk


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