Re: Image transformations

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Copley <rcopley@gmail.com>
> Date: Fri, 14 Jun 2019 12:21:19 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, Emacs Development <emacs-devel@gnu.org>
> 
> 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?

Two reasons: (a) Emacs is not a system for graphics programming, and
doesn't target programmers in that domain; (2) an API based on
transformation matrices is IMO too low-level, unlike anything else in
Emacs.

> (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?)

I'm using this site when I need information about older versions of
Windows:

  http://winapi.freetechsecrets.com/win32

According to it, GM_ADVANCED is not supported on Windows 9X.

> Secondly, for users who want to specify a scale, translation and
> rotation, it's easy to construct the matrix from that
> information.

"Easy"?  For those with background in graphics programming, sure.  For
others, not so sure.

> (All the graphics libraries provide helper functions for this, and
> so should we.)

So you are saying that we should accept the attributes and convert
them to a matrix in Lisp?  That might work, and doesn't really
contradict what I say above, but we should first make sure that all
the toolkits we support interpret the matrix the same.  We are still
arguing about the meaning we ourselves assign to the matrix (see the
recent clockwise vs counter-clockwise rotation issue), which somehow
doesn't increase my confidence that exposing the transformation
through a Lisp API would be a good/useful idea.

> 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.

I still don't understand why users would want to specify
transformations via a matrix.

> Thirdly, the homogeneous matrix is compact and uniform, and makes
> it easy to compose and invert (undo) transformations.

So are/do the attributes.  Which representation is more compact is
arguable: for example, the matrix representation of a rotation is much
more wasteful than just a single angle of rotation parameter.

But I think this is a tangent, because my proposal doesn't preclude
providing a matrix-based API in the future.