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

[Rik Cabanier]

On Mon, Mar 17, 2014 at 2:41 PM, Rik Cabanier <cabanier at gmail.com> wrote:

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

It would be great if we could get clarification on this.
Firefox and IE are conformant per the spec when it comes to drawing paths
but not fill/stroke/clip. Supporting this small edge case comes at a large
cost in Firefox and likely also IE.

Many APIs in canvas are running into this issue which results in lack of
interoperability.