[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Testing native image scaling

From: Alan Third
Subject: Re: Testing native image scaling
Date: Sun, 20 Jan 2019 19:26:31 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Sun, Jan 20, 2019 at 06:05:18PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 19 Jan 2019 21:45:43 +0000
> > From: Alan Third <address@hidden>
> > Cc: address@hidden
> > 
> > x_set_image_size calculates the new sizes, does the conversion, and
> > writes those new sizes back into struct image, over‐writing the
> > original sizes.
> > 
> > For NS it also asks the NSImage back‐end to scale the image using
> > ns_image_set_size, which in effect does the actual scaling.
> > 
> > For XRender it sets up an affine transformation matrix, and applies it
> > to img->picture, which also in effect does the actual scaling.
> > 
> > The compositing functions in nsterm.m and xterm.c don’t need to know
> > the original image size, just the new size, and NSImage/XRender
> > handles the rest.
> Well, on w32, the implementation actually resizes when it draws.
> Maybe that's sub-optimal, but I know next to nothing about w32 image
> display, so what I got looks definitely fine for my ignorance.

I believe that with XRender, and possibly with NS, the actual resizing
is done at draw time, it’s just that the drawing functions don’t need
to know about it because it’s already built into the image types.

> So we now have native resizing on all major platforms.

Excellent! Thanks!

> > We could use XRender to rotate images if we really wanted to, and the
> > NS port already supports it.
> Where's the NS support for that?  AFAICT, :rotate is only handled in
> ImageMagick specific portions of the code, what did I miss?

It’s buried in nsimage.m, ns_load_image gets both :rotation and
:index, then processes the image as appropriate.

If we were to add XRender rotation support, I’d be tempted to do both
rotation and scaling using affine transformation matrices in both
XRender and NS, as they would then both use the same code to calculate
the transforms. I believe Windows supports transformation matrices
through D2D, but I assume Emacs doesn’t use D2D currently, so it may
not be straight forward to add.

If we were to go that far, it may be worth actually exposing the
matrices to lisp and handle the calculations there, but that would
potentially be a big change to the API.
Alan Third

reply via email to

[Prev in Thread] Current Thread [Next in Thread]