Re: Testing native image scaling

[Alan Third]

On Sat, Jan 19, 2019 at 11:31:34AM +0200, Eli Zaretskii wrote:
> Alan, could you please tell how you tested native image scaling with
> the XRENDER extension, and perhaps show some Lisp or existing commands
> you used for that?  E.g., did the features in thumbs.el work for you
> in a build without Imagemagick?

I just used a fairly simple series of commands like this:

(setq i (create-image "~/image.png" nil nil :scale 0.5))
(insert-image i)
(setq ii (create-image "~/image.png" nil nil :scale 0.5))
(insert "\n")
(insert-image ii)
(insert "\n")
(insert "x")
(insert-image i)
(insert "x")
(insert "\n")

(setq i (create-image "~/image.png" nil nil :scale 0.25
                      :margin 10 :relief 10))
(insert-image i)

(insert "x")
(insert "\n")

(setq i (create-image "~/image.png" nil nil :width 25))
(insert-image i)

I was testing with animated gifs at one stage, which is why I was
using setq. I also found various files using C-x C-f.

It look like thumbs.el uses ImageMagick’s convert program directly, so
it won’t be affected by native scaling.

> I tried to implement this for MS-Windows, but I guess my understanding
> of the internal workings of this is incomplete/incorrect, or my code
> is buggy (or both), because I don't seem to be able to cause Emacs to
> exercise the code when the original image's size and the size
> requested by scaling differ.  For example, I thought that when scaling
> is requested, x_set_image_size should be called and compute image
> dimensions different from the original img->height and img->width, but
> I seem to be unable to see this.  What am I missing?  Could you
> perhaps describe the flow of calls when, e.g., the user types '+' on
> an image in image-mode, and Emacs scales the image at point?

I think you understand this right.

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.

There are only two potential problems I can see:

1. If you’re building with ImageMagick, then when you hit + in
image-mode it automatically reverts to ImageMagick as a back end. In
that case x_set_image_size won’t do anything since ImageMagick will
have already resized the image. If you insert images directly into a
buffer like I did in the script above then ImageMagick will never be
used unless you explicitly request it.

2. If you missed the fact that img->width/height are set within
#ifdef/#endif blocks. That is due to the requirement of checking
img->picture for XRender, although there are plenty of other ways to
handle it.

> P.S. Incidentally, image-scaling-p is called in image.el also in
> context where we want to know whether an image can be rotated by 90
> degrees, and native scaling doesn't support that, does it?

That’s correct. I should have created new separate functions for
testing rotation and scaling.

We could use XRender to rotate images if we really wanted to, and the
NS port already supports it.

-- 
Alan Third