Re: [whatwg] Singular CTM and currentTransform
Maklng path primitives and draw calls no-ops when the CTM is non-invertible is simple to spec, implement, test, and understand for developers. I strongly agree on Justin. 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(); afaik, we generally avoid throwing exception. am I right? Br, DS
Re: [whatwg] Singular CTM and currentTransform
On Mar 26, 2014, at 1:07 PM, Hwang, Dongseong dongseong.hw...@intel.com wrote: Maklng path primitives and draw calls no-ops when the CTM is non-invertible is simple to spec, implement, test, and understand for developers. I strongly agree on Justin. I agree as well. 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(); afaik, we generally avoid throwing exception. am I right? Canvas throws a lot actually but I am open for option 2 as well. Greetings, Dirk Br, DS
[whatwg] Singular CTM and currentTransform
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 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.
Re: [whatwg] Singular CTM and currentTransform
On Tue, Mar 25, 2014 at 8:25 AM, Dirk Schulze dschu...@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. 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.
Re: [whatwg] Singular CTM and currentTransform
On Tue, Mar 25, 2014 at 8:49 AM, Justin Novosad ju...@google.com wrote: On Tue, Mar 25, 2014 at 8:25 AM, Dirk Schulze dschu...@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.
Re: [whatwg] Singular CTM and currentTransform
On Tue, Mar 25, 2014 at 3:15 PM, Rik Cabanier caban...@gmail.com wrote: 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? I'm in a holding pattern. 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. Right now, there is no browser interoperability when using non-invertible CTMs, and the web has been in this inconsistent state for a long time. The fact that this issue has never escalated (AFAIK) is a strong hint that no one out there really cares about this use case, so we should probably just go for simplicity. Maklng path primitives and draw calls no-ops when the CTM is non-invertible is simple to spec, implement, test, and understand for developers. 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.
Re: [whatwg] Singular CTM and currentTransform
On Tue, Mar 25, 2014 at 12:35 PM, Justin Novosad ju...@google.com wrote: On Tue, Mar 25, 2014 at 3:15 PM, Rik Cabanier caban...@gmail.com wrote: 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? I'm in a holding pattern. 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. Right now, there is no browser interoperability when using non-invertible CTMs, and the web has been in this inconsistent state for a long time. The fact that this issue has never escalated (AFAIK) is a strong hint that no one out there really cares about this use case, so we should probably just go for simplicity. Maklng path primitives and draw calls no-ops when the CTM is non-invertible is simple to spec, implement, test, and understand for developers. Great to hear! I volunteer to update the Firefox implementation if we can get consensus. (see https://bugzilla.mozilla.org/show_bug.cgi?id=931587) 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.
Re: [whatwg] Singular CTM and currentTransform
On Mar 25, 2014, at 8:46 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Mar 25, 2014 at 12:35 PM, Justin Novosad ju...@google.com wrote: On Tue, Mar 25, 2014 at 3:15 PM, Rik Cabanier caban...@gmail.com wrote: 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? I'm in a holding pattern. 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. Right now, there is no browser interoperability when using non-invertible CTMs, and the web has been in this inconsistent state for a long time. The fact that this issue has never escalated (AFAIK) is a strong hint that no one out there really cares about this use case, so we should probably just go for simplicity. Maklng path primitives and draw calls no-ops when the CTM is non-invertible is simple to spec, implement, test, and understand for developers. Great to hear! I volunteer to update the Firefox implementation if we can get consensus. (see https://bugzilla.mozilla.org/show_bug.cgi?id=931587) Speaking for WebKit, support for changing the spec from me as well. Doing it according to the spec would be difficult, if possible at all in WebKit. Greetings, Dirk 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.
