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

[Rik Cabanier]

On Mon, Mar 17, 2014 at 10:18 AM, Justin Novosad <junov at google.com> wrote:

>
>
>
> On Mon, Mar 17, 2014 at 12:59 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>>
>>
>>
>> On Mon, Mar 17, 2014 at 8:45 AM, Justin Novosad <junov at google.com> wrote:
>>
>>> On Mon, Mar 17, 2014 at 11:35 AM, Dirk Schulze <dschulze at adobe.com>
>>> wrote:
>>>
>>> >
>>> > > Hmmm, I gave this a bit more thought...  To apply the construction
>>> > > algorithm in transformed space, the ellipse parameters (radiusX,
>>> radiusY,
>>> > > rotation) would have to be transformed. Transforming the parameters
>>> would
>>> > > be intractable under a projective transform (e.g. perspective), but
>>> since
>>> > > we are limitted to affine transforms, it can be done.  Now, in the
>>> case
>>> > of
>>> > > a non-invertible CTM, we would end up with radiusX or radiusY or both
>>> > equal
>>> > > to zero.  And what happens when you have that?  Your arcTo just
>>> turned
>>> > into
>>> > > lineTo(x1, y1). Tada!
>>> >
>>> > Why does radiusX or radiusY need to be zero? Because you define it that
>>> > way for a non-invertible matrix? That makes sense for scale(0,0). What
>>> > about infinity or NaN? If Ian didn't update the spec then this is still
>>> > undefined and therefore up to the UA to decide.
>>> >
>>> >
>>> Oh yeah, I was totally forgetting about singularities caused by
>>> non-finite
>>> values.  Could we just the same agree to resolve that case by treating
>>> arcTo as lineTo(x1, y1) in the case of a non-invertible CTM?  Or do you
>>> think there is a more logical thing to do?
>>>
>>
>> Make a clean cut and define that drawing operators are ignored when
>> there's a non-invertible matrix.
>>
>> I could totally go for that, but you are talking about going back on the
> spec of a feature that has shipped, as opposed to clarifying edges cases.
> Maybe that would be fine in this case though...
>

I'm unsure if anyone has shipped that part of the spec. There's certainly
no interop...

Looking at the implementation in Blink and WebKit, all of the drawing
methods and fill/stroke/clip start with:

    if (!isTransformInvertible())
        return;


At first glance, Firefox seems to do what the spec says (which results in
slow double transforming of all coordinates) but then they punt as well:

Matrix inverse = mTarget->GetTransform();
if (!inverse.Invert()) {

NS_WARNING("Could not invert transform");

return;

}


So, what we could say is:
- when drawing paths, ignore all calls if the matrix is non-invertible
(WebKit and Blink do this)
- when filling/stroking/clipping, ignore all calls if the matrix is
non-invertible (Firefox, WebKit and Blink do this)