Perspective transforms for Canvas2D

[fserb]

Allow for perspective (non-affine) 2D transforms. Non-affine transforms are
transformations where parallel lines don't remain parallel after the transform.

Working proposal: https://github.com/fserb/canvas2D/blob/master/spec/perspective-transforms.md

(cc @whatwg/canvas )

[litherum]

This would be extremely difficult to implement in WebKit's architecture. Core Graphics doesn't have any facility for 3d operations. Trying to split a canvas into a Core Animation layer hierarchy would be a world of pain.

If authors want this effect, they can transform multiple canvas elements using CSS 3D transforms. Or, use WebGL.

The benefit doesn't seem worth the cost.

[kdashg]

Isn't this just a helper function for explicit setTransform?

[fserb]

@jdashg, not really. The proposal here would be to allow also non-affine transforms (like CSS does). Canvas2D already has rotate/scale/translate. This would add a optional 3rd dimension to some of those, to allow perspective transformations.

[kdashg]

Ah, it's pretty subtle that setTransform runs only the 2d dictionary constructor for DOMMatrix, which is otherwise 3d-capable by spec.

[fserb]

Exactly. The proposal here is to match the CSS capabilities inside Canvas and just support the full DOMMatrix.

[dbaron]

A few comments after looking over the proposal quickly:

• The rotate3d method proposed here (taking 3 angles) is different from the CSS rotate3d() function (which takes 3 components of a vector and a single angle). This seems like a surprising difference. It also requires specifying how the angles compound with each other when more than one of them are nonzero, and whatever rules you come up with for that might end up being surprising in some cases. Whereas your proposed rotateAxis() is equivalent to CSS's rotate3d(). I'd argue in favor of naming consistency, and I'm also concerned about the 3-angle form being confusing.

• if you're using 4x4 matrices, something needs to specify the handling of the w in the result, as CSS Transforms does in § 4.2. Processing of Perspective-Transformed Boxes.

[mysteryDate]

Whereas your proposed rotateAxis() is equivalent to CSS's rotate3d(). I'd argue in favor of naming consistency, and I'm also concerned about the 3-angle form being confusing.

The thinking here was that it would be more valuable to match popular and well established 3d APIs like three.js, unreal and Unity as opposed to CSS in this instance. rotateAxis is definitely more useful than the rotate3d Euler rotations, but the most requested use cases are things like card flipping and text crawls. In lieu of adding three separate rotateX, rotateY, rotateZ functions, we decided to go with just one. Euler angles always get surprising when pushed to their limits, this feels like a limitation of most 3d platforms.

[tabatkins]

I feel pretty strongly that, even if established 3d APIs have a different 3d rotation primitive, we shouldn't use the existing CSS name for that new primitive and put the CSS function under a different name. Learnability and consistency generally leans strongly on letting the CSS function use its native name, and giving the new/better thing a different name; exceptions would only be if, say, the existing CSS functionality is just straight-up a mistake that shouldn't be repeated.

[tabatkins]

Fwiw, then, I think you should just add the three rotateX/Y/Z functions, since they're already in CSS Transforms, and if 3d libraries usually have a 3-angle version that takes all three and composes them in a particular order, then add that additionally as rotateAngle or something.

[mysteryDate]

Fwiw, then, I think you should just add the three rotateX/Y/Z functions, since they're already in CSS Transforms, and if 3d libraries usually have a 3-angle version that takes all three and composes them in a particular order, then add that additionally as rotateAngle or something.

This seems fair to me, if I remember correctly (big if) that was my original approach. Composing Euler angles is tricky and surprising and I'm generally for discouraging it. So, how does consensus feel about the rotation api being:

• rotateX, rotateY, rotateZ
• rotateAxis (supply x, y, z axis and rotation around that axis)

This lets us avoid the whole rotate3d naming thing entirely.

[jrmuizel]

FWIW, cairo (WebKitGTK) doesn't support perspective transforms either.