On Mar 17, 2014, at 9:23 PM, Justin Novosad <ju...@google.com> wrote:
> > > > On Mon, Mar 17, 2014 at 2:06 PM, Rik Cabanier <caban...@gmail.com> wrote: > > > > > 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... > > Plenty of browser have shipped drawing paths to canvas. I agree about the no > interop part. It is the main reason I think it may still be acceptable to > redefine the spec. > > > 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) > > Yes, but there is still an issue that causes problems in Blink/WebKit: > because the canvas rendering context stores its path in local (untransformed) > space, whenever the CTM changes, the path needs to be transformed to follow > the new local spcae. This transform requires the CTM to be invertible. So > now webkit and blink have a bug that causes all previously recorded parts of > the current path to be discarded when the CTM becomes non-invertible (even if > it is only temporarily non-invertible, even if the current path is not even > touched while the matrix is non-invertible). 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. Are you sure about this? The path should stay untouched during the time the CTM is not invertible. At least in WebKit I can not remember that I see the path discarded. As Rik quoted in the code snippet, we just return silently and do not touch the path and avoid daring operations. Greetings, Dirk >