W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

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

From: Justin Novosad <junov@google.com>
Date: Mon, 17 Mar 2014 14:30:18 -0700
Message-ID: <CABpaAqSCPRPk84=z4Ad3LhO6zP7FMV5hSez-SB77uOGyawV9Sw@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Dirk Schulze <dschulze@adobe.com>, WHATWG List <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
On Mon, Mar 17, 2014 at 2:18 PM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> On Mon, Mar 17, 2014 at 1:47 PM, Justin Novosad <junov@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.
Received on Monday, 17 March 2014 21:30:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC