- From: Justin Novosad <junov@google.com>
- Date: Mon, 17 Mar 2014 14:30:18 -0700
- 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