You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am investigating some css transform wpt test failures for WebKit and https://www.w3.org/TR/css-transforms-1/#interpolation-of-2d-matrices, specifically the calculation of scale, produces a different scale than what produced the transformation matrix when there is also a skew value. For example in css/css-transforms/animation/transform-interpolation-005.html, there is an interpolation from scaleY(7) -> skewX(45deg)scaleX(7). The decomposition of the scaleY matrix produces the expected decomposed functions, however for the skewX scaleX matrix, we are getting scale(7, 1.414)m = [1 0 0.707 0.707]. When blended at 0.5 with the scaleY matrix we get scale(4,4.21) m = [1 0 0.35 0.85] which recomposes to matrix(4 0 1.49 3.59 0 0), which doesn't match the expected matrix matrix(4 0 2 4 0 0).
Clearly scale(7, 1.414) doesn't match scaleX(7), however from my understanding we are following correctly how the spec calculates scale, since it is clear that in scale[1] = sqrt(row1x * row1x + row1y * row1y), this calculation is being impacted by the presence of a skew value. The unmatrix method being referenced in the spec only guarantees that the decomposed functions would result in the same matrix when recomposed (which it does in this case), and doesn't necessarily guarantee that they will be the same as the functions that originally produced that matrix. My question is, is it guaranteed that the blending of these decomposed functions would be the same as blending the original functions that produced the transform matrix? If it is the case that is guaranteed, if someone could help understand how we are not following the spec, that would be helpful.
The text was updated successfully, but these errors were encountered:
My (probably wrong) understanding is that the common decomposition techniques don't account for skew, because it is the ugly step-child of transformations.
But that doesn't explain why WebKit is failing the test if other implementations are passing. Have you looked into what their code actually does?
Interestingly, while FireFox does have a decompose function that implements the spec (which is why I was confused as to how it was passing these skew tests), it appears to actually be using a different decompose function. This decompose function seems to be using the same transform functions that decompose3d uses.
I am investigating some css transform wpt test failures for WebKit and https://www.w3.org/TR/css-transforms-1/#interpolation-of-2d-matrices, specifically the calculation of scale, produces a different scale than what produced the transformation matrix when there is also a skew value. For example in css/css-transforms/animation/transform-interpolation-005.html, there is an interpolation from
scaleY(7)
->skewX(45deg)
scaleX(7)
. The decomposition of the scaleY matrix produces the expected decomposed functions, however for the skewX scaleX matrix, we are gettingscale(7, 1.414)
m = [1 0 0.707 0.707]
. When blended at0.5
with the scaleY matrix we getscale(4,4.21)
m = [1 0 0.35 0.85]
which recomposes tomatrix(4 0 1.49 3.59 0 0)
, which doesn't match the expected matrixmatrix(4 0 2 4 0 0).
Clearly
scale(7, 1.414)
doesn't matchscaleX(7)
, however from my understanding we are following correctly how the spec calculates scale, since it is clear that inscale[1] = sqrt(row1x * row1x + row1y * row1y)
, this calculation is being impacted by the presence of a skew value. The unmatrix method being referenced in the spec only guarantees that the decomposed functions would result in the same matrix when recomposed (which it does in this case), and doesn't necessarily guarantee that they will be the same as the functions that originally produced that matrix. My question is, is it guaranteed that the blending of these decomposed functions would be the same as blending the original functions that produced the transform matrix? If it is the case that is guaranteed, if someone could help understand how we are not following the spec, that would be helpful.The text was updated successfully, but these errors were encountered: