[whatwg] [Canvas] Behavior on non-invertable CTM

[Rik Cabanier]

On Mon, Mar 17, 2014 at 2:30 PM, Justin Novosad <junov at google.com> wrote:

>
>
>
> On Mon, Mar 17, 2014 at 2:18 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>>
>> On Mon, Mar 17, 2014 at 1:47 PM, Justin Novosad <junov at google.com> wrote:
>>
>>>
>>>
>>>>
>>>>
>>>>> I have a fix in flight that fixes that problem in Blink by storing the
>>>>> current path in transformed coordinates instead. I've had the fix on the
>>>>> back burner pending the outcome of this thread.
>>>>>
>>>>
>>>> That seems like an expensive solution because this causes the
>>>> coordinates to be transformed twice.
>>>> Why not store the matrix that was applied to the path coordinates and
>>>> use that to undo the transformation?
>>>>
>>>
>> Dirk and I looked over the WebKit code and it's actually already doing
>> this.
>>
>
> Good, maybe that can be the reference then.
>
>
>>
>>
>>> If we decide that the right thing is to do nothing when when the CTM is
>>> non-invertible, then sure, we can just do that. The idea of storing the
>>> current path in transformed coordinates was to also support drawing with a
>>> non-invertible CTM, like Firefox does, which is what Ian stated was the
>>> correct behavior earlier in this thread.
>>>
>>
>> yeah, but then FF bails at draw time anyway.
>>
>
> Only if the CTM is still non-invertible at draw time.  If the CTM was
> transiently non-invertible during the path construction, FF produces
> results consistent with applying the transform to the points used to
> construct the path, which is technically compliant with the current wording
> of the spec.
>

That's correct. If someone did this in Firefox:

ctx.setTransform(1,1,1,1,0,0);

ctx.moveto(0,0);

ctx.lineTo(10,0);

ctx,setTransform(1,0,0,1,0,0);

ctx.fill();

the end result would be a line from (0,0) to (10, 10). (IE does this as
well).
Nothing draws in Safari and Chrome currently.