Re: [whatwg] <canvas> feedback

On Tue, Apr 8, 2014 at 12:25 PM, Justin Novosad <junov@google.com> wrote:

>
> >
> > On Mon, 17 Mar 2014, Justin Novosad wrote:
> > >
> > > 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.
> >
> > Indeed. It's possible to pick implementation strategies that just can't
> be
> > compliant; we shouldn't change the spec every time any implementor
> happens
> > to make that kind of mistake, IMHO.
> >
> > (Of course the better long-term solution here is the Path objects, which
> > are transform-agnostic during building.)
> >
> >
> > Just to be clear, we should support this because otherwise the results
> are
> > just wrong. For example, here some browsers currently show a straight
> line
> > in the default state, and this causes the animation to look ugly in the
> > transition from the first frame to the secord frame (hover over the
> yellow
> > to begin the transition):
> >
> >    http://junkyard.damowmow.com/538
> >
> > Contrast this to the equivalent code with the transforms explicitly
> > multiplied into the coordinates:
> >
> >    http://junkyard.damowmow.com/539
> >
> > I don't see why we would want these to be different. From the author's
> > perspective, they're identical.
>

These examples are pretty far fetched.
How many time do people change the CTM in the middle of a drawing operation
and not change the geometry?

If we stick to that, there are still some behaviors that need to resolved.
> One issue that comes to mind is what happens if stroke or fill are called
> while the CTM is non-invertible? To be more precise, how would the styles
> be mapped?  If the fillStyle is collapsed to a point, does that mean the
> path gets filled in transparent black?  If we go down this road, we will
> likely uncover more questions of this nature.


Indeed


> > On Tue, 25 Mar 2014, Justin Novosad wrote:
> > >
> > > I prepared a code change to that effect, but then there was talk of
> > > changing the spec to skip path primitives when the CTM is not
> > > invertible, which I think is a good idea. It would avoid a lot of
> > > needless hoop jumping on the implementation side for supporting weird
> > > edge cases that have little practical usefulness.
> >
> > I'm not sure I agree that they have little practical usefulness. Zeros
> > often occur at the edges of transitions, and if we changed the spec then
> > these transitions would require all the special-case code to go in author
> > code instead of implementor code.
> >
>
> Yes, I think that may be the strongest argument so far in this discussion.
> The examples you provided earlier illustrate it well.
> I would like to hear what Rik and Dirk think about this now.
>

I looked at the webkit and chrome bug databases and I haven't found anyone
who complained about their current behavior.
Implementing this consistently will either add a bunch of special case code
to deal with non-singular matrices or double (triple?) conversion of all
segment points like firefox does. After that, fill, stroke and clip will
still not work when there's a non-invertible matrix.

I do not think it's worth the effort...

Received on Tuesday, 8 April 2014 22:10:35 UTC