On Mon, Mar 17, 2014 at 2:30 PM, Justin Novosad <[email protected]> wrote:
> > > > On Mon, Mar 17, 2014 at 2:18 PM, Rik Cabanier <[email protected]> wrote: > >> >> >> >> On Mon, Mar 17, 2014 at 1:47 PM, Justin Novosad <[email protected]> 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. > That's correct. If someone did this in Firefox: ctx.setTransform(1,1,1,1,0,0); ctx.moveto(0,0); ctx.lineTo(10,0); ctx,setTransform(1,0,0,1,0,0); ctx.fill(); the end result would be a line from (0,0) to (10, 10). (IE does this as well). Nothing draws in Safari and Chrome currently.
