[whatwg] Singular CTM and currentTransform

[Rik Cabanier]

On Tue, Mar 25, 2014 at 8:49 AM, Justin Novosad <junov at google.com> wrote:

> On Tue, Mar 25, 2014 at 8:25 AM, Dirk Schulze <dschulze at adobe.com> wrote:
>
> > Hi,
> >
> > Independent if getter getTransform/getCTM or attribute currentTransform,
> > what should be returned for a CTM that is singular (not invertible)?
> >
> > In WebKit we do not track all transformations of the CTM that caused a
> > singular matrix or are following a transformation that would have caused
> a
> > singular matrix.
> >
> > Example:
> >
> > ctx.scale(0,0);
> > ct.translate(10,10);
> >
> > In webkit we would not apply the transformation scale(0,0) and mark the
> > CTM as not-invertible instead. So we could not return an SVGMatrix object
> > with a = b = c = d = 0; e = f = 10 because we actually don't know the CTM
> > after applying all transforms.
> >
> > I would suggest that the getter either:
> > 1) throws and invalid state error if the CTM is not invertible
> > 2) returns 0. In WebIDLit would look like: SVGMatrix? getTransform();
> >
> > Greetings,
> > Dirk
> >
>
> The notion that an invertible matrix is an unusable state is somewhat of a
> webkit-ism.  I think there is a prerequisite question that needs to be
> resolved before we can ponder what you propose: should we proceed with draw
> operations when the canvas is non-invertible?  Right now some browsers do
> and some don't. The current state of the spec suggests that webkit/blink
> are *not* doing the right thing.  In another thread we discussed skipping
> path primitives (and presumably all draw calls) when the matrix is
> non-invertible. We should probably finalize that issue first.


I agree. That issue has the same root problem as currentTransform.
It would be nice to get closure.

Justin, you hinted that you would be willing to follow the spec which would
make you match Firefox and IE.
Are still planning on doing that?

Note that Firefox is still non-compliant if there's a non-invertible matrix
during filling/stroking/clipping


> > PS: This is one reason I prefer a getter over an attribute because the
> > getter does not return a mutable (live) SVGMatrix. But even than the
> > problem above is not fully solved of course.
>