> From: Stefan Monnier <address@hidden>
> Date: Fri, 14 Jun 2019 05:57:21 -0400
>
> > I think this would be a wasted effort. There's no need to make all
> > the implementations use the same matrix, unless they all assign the
> > same semantics to the matrix -- which doesn't appear to be the case,
> > at least not as far as this discussion shows.
>
> There's one case where this would make sense: if we decide to let Elisp
> provide such a matrix.
Why would providing a matrix interface be a good idea? I think an
interface based on attributes (:crop, :rotation, etc.) is much cleaner
and easier to use. We can always add more attributes (like :shear) if
we want.
What am I missing?
Firstly, all the 2D graphics libraries (XRender and NS, as we have seen, GDI,
Direct2D, HTML5 Canvas, Cairo) specify the transformation with a homogeneous
matrix. (The same goes for 3D graphics libraries.) It's fundamental to graphics
programming. Why make up our own, inferior, system?
(The Windows API documentation is no longer very good for finding out about
previous versions of Windows. Is GM_ADVANCED not supported on some GDI
versions we're interested in? If so, is it important to provide image support there?)
Secondly, for users who want to specify a scale, translation and rotation, it's
easy to construct the matrix from that information. (All the graphics libraries
provide helper functions for this, and so should we.) On the other hand for
users who want to specify the homogeneous matrix, it's not easy to decompose the
matrix into scale, shear, rotation and translation and rotation.
it easy to compose and invert (undo) transformations.