Re: Image transformations

[Richard Copley <rcopley@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

On Fri, 14 Jun 2019 at 11:59, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > 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.

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

[-- Attachment #2: Type: text/html, Size: 2495 bytes --]