* Testing native image scaling @ 2019-01-19 9:31 Eli Zaretskii 2019-01-19 21:45 ` Alan Third 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-01-19 9:31 UTC (permalink / raw) To: Alan Third; +Cc: emacs-devel 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 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? Thanks. 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-01-19 9:31 Testing native image scaling Eli Zaretskii @ 2019-01-19 21:45 ` Alan Third 2019-01-20 16:05 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Alan Third @ 2019-01-19 21:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-01-19 21:45 ` Alan Third @ 2019-01-20 16:05 ` Eli Zaretskii 2019-01-20 19:26 ` Alan Third 2019-03-27 2:35 ` YAMAMOTO Mitsuharu 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2019-01-20 16:05 UTC (permalink / raw) To: Alan Third; +Cc: emacs-devel > Date: Sat, 19 Jan 2019 21:45:43 +0000 > From: Alan Third <alan@idiocy.org> > Cc: emacs-devel@gnu.org > > 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) Thanks, this was very helpful. (Actually, just create-image with one argument is enough: after inserting it, '+' or '-' on the image will interactively resize it.) > It look like thumbs.el uses ImageMagick’s convert program directly, so > it won’t be affected by native scaling. Ah, okay, I missed that. image-dired seems to do the same. I guess we should at some point update those (and others) to use the native resizing. > > 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. 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. So we now have native resizing on all major platforms. > 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? Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-01-20 16:05 ` Eli Zaretskii @ 2019-01-20 19:26 ` Alan Third 2019-01-20 19:41 ` Eli Zaretskii 2019-03-27 2:35 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 18+ messages in thread From: Alan Third @ 2019-01-20 19:26 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 <alan@idiocy.org> > > Cc: emacs-devel@gnu.org > > > > 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-01-20 19:26 ` Alan Third @ 2019-01-20 19:41 ` Eli Zaretskii 2019-01-20 20:19 ` Alan Third 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-01-20 19:41 UTC (permalink / raw) To: Alan Third; +Cc: emacs-devel > Date: Sun, 20 Jan 2019 19:26:31 +0000 > From: Alan Third <alan@idiocy.org> > Cc: emacs-devel@gnu.org > > > 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. Thanks, I will take a look. > 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. Windows can calculate and use transformation matrices without D2D as well, it's really quite simple. You calculate the matrix elements, and then call a function to install it for the next BitBlt. > If we were to go that far, it may be worth actually exposing the > matrices to lisp and handle the calculations there What advantages would that give us? Wouldn't it be better to support higher-level abstractions for the transformations, like scaling, rotation, and shear? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-01-20 19:41 ` Eli Zaretskii @ 2019-01-20 20:19 ` Alan Third 0 siblings, 0 replies; 18+ messages in thread From: Alan Third @ 2019-01-20 20:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Sun, Jan 20, 2019 at 09:41:02PM +0200, Eli Zaretskii wrote: > > > 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. > > Windows can calculate and use transformation matrices without D2D as > well, it's really quite simple. You calculate the matrix elements, > and then call a function to install it for the next BitBlt. Sounds very similar to how XRender works. It might be worth giving this a go, then. > > If we were to go that far, it may be worth actually exposing the > > matrices to lisp and handle the calculations there > > What advantages would that give us? Wouldn't it be better to support > higher-level abstractions for the transformations, like scaling, > rotation, and shear? It would simplify the C code, and move those higher level abstractions into lisp. I’m not sure if that’s a good thing, but hasn’t it been the stated intention of the Emacs project for a while? It would make it harder to understand for a human what any given image spec would be expected to do, but then I don’t know if humans look at image specs much. -- Alan Third ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-01-20 16:05 ` Eli Zaretskii 2019-01-20 19:26 ` Alan Third @ 2019-03-27 2:35 ` YAMAMOTO Mitsuharu 2019-03-27 17:09 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: YAMAMOTO Mitsuharu @ 2019-03-27 2:35 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Alan Third, emacs-devel On Mon, 21 Jan 2019 01:05:18 +0900, Eli Zaretskii wrote: > > > Date: Sat, 19 Jan 2019 21:45:43 +0000 > > From: Alan Third <alan@idiocy.org> > > Cc: emacs-devel@gnu.org > > > > 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) > > Thanks, this was very helpful. (Actually, just create-image with one > argument is enough: after inserting it, '+' or '-' on the image will > interactively resize it.) I think we should test sliced images as well. (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 3 5) Actually, I suspect this does not work on W32 because the comparison with the original image size is made for s->slice.width (or height) rather than s->img->width (or height) as I just did for cairo code. Could you check it on W32? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-27 2:35 ` YAMAMOTO Mitsuharu @ 2019-03-27 17:09 ` Eli Zaretskii 2019-03-27 18:35 ` Andy Moreton 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-03-27 17:09 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: alan, emacs-devel > Date: Wed, 27 Mar 2019 11:35:26 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: Alan Third <alan@idiocy.org>, > emacs-devel@gnu.org > > (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 3 5) > > Actually, I suspect this does not work on W32 because the comparison > with the original image size is made for s->slice.width (or height) > rather than s->img->width (or height) as I just did for cairo code. > Could you check it on W32? It seems to work, but maybe I don't know what and how to check. Can you show what I should expect to see with and without the :scale attribute, in "emacs -Q"? Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-27 17:09 ` Eli Zaretskii @ 2019-03-27 18:35 ` Andy Moreton 2019-03-27 18:42 ` Eli Zaretskii 2019-03-28 2:26 ` YAMAMOTO Mitsuharu 0 siblings, 2 replies; 18+ messages in thread From: Andy Moreton @ 2019-03-27 18:35 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 922 bytes --] On Wed 27 Mar 2019, Eli Zaretskii wrote: >> Date: Wed, 27 Mar 2019 11:35:26 +0900 >> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> >> Cc: Alan Third <alan@idiocy.org>, >> emacs-devel@gnu.org >> >> (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 3 5) >> >> Actually, I suspect this does not work on W32 because the comparison >> with the original image size is made for s->slice.width (or height) >> rather than s->img->width (or height) as I just did for cairo code. >> Could you check it on W32? > > It seems to work, but maybe I don't know what and how to check. Can > you show what I should expect to see with and without the :scale > attribute, in "emacs -Q"? > > Thanks. I would expect a sliced image to be composed of a grid of tiled images instead of a single image, but to have the same visual appearance as the original image. The w32 code does not get this right. [-- Attachment #2: w32-sliced-image.png --] [-- Type: image/png, Size: 18415 bytes --] [-- Attachment #3: Type: text/plain, Size: 182 bytes --] Adding the ":scale 0.5" argument scales down the tiled array of images correctly, but they still contain the same display artifacts as the sliced image without scaling. AndyM ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-27 18:35 ` Andy Moreton @ 2019-03-27 18:42 ` Eli Zaretskii 2019-03-27 19:06 ` Andy Moreton 2019-03-28 2:26 ` YAMAMOTO Mitsuharu 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-03-27 18:42 UTC (permalink / raw) To: Andy Moreton; +Cc: emacs-devel > From: Andy Moreton <andrewjmoreton@gmail.com> > Date: Wed, 27 Mar 2019 18:35:09 +0000 > > > It seems to work, but maybe I don't know what and how to check. Can > > you show what I should expect to see with and without the :scale > > attribute, in "emacs -Q"? > > I would expect a sliced image to be composed of a grid of tiled images > instead of a single image, but to have the same visual appearance as the > original image. The w32 code does not get this right. Did insert-sliced-image ever work on Windows, even before scaling was added? > Adding the ":scale 0.5" argument scales down the tiled array of images > correctly, but they still contain the same display artifacts as the > sliced image without scaling. Thanks, but I asked for the _correct_ image I need to expect, because I want something to compare to if/when I decide to try to fix this. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-27 18:42 ` Eli Zaretskii @ 2019-03-27 19:06 ` Andy Moreton 2019-03-27 19:34 ` Andy Moreton 0 siblings, 1 reply; 18+ messages in thread From: Andy Moreton @ 2019-03-27 19:06 UTC (permalink / raw) To: emacs-devel On Wed 27 Mar 2019, Eli Zaretskii wrote: >> From: Andy Moreton <andrewjmoreton@gmail.com> >> Date: Wed, 27 Mar 2019 18:35:09 +0000 >> >> > It seems to work, but maybe I don't know what and how to check. Can >> > you show what I should expect to see with and without the :scale >> > attribute, in "emacs -Q"? >> >> I would expect a sliced image to be composed of a grid of tiled images >> instead of a single image, but to have the same visual appearance as the >> original image. The w32 code does not get this right. > > Did insert-sliced-image ever work on Windows, even before scaling was > added? > >> Adding the ":scale 0.5" argument scales down the tiled array of images >> correctly, but they still contain the same display artifacts as the >> sliced image without scaling. > > Thanks, but I asked for the _correct_ image I need to expect, because > I want something to compare to if/when I decide to try to fix this. Sorry - I thought that was clear. The following forms should all produce the same visual appearance in the buffer: (insert-image (create-image "splash.png" nil nil :scale 0.5)) (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 1 1) (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 3 5) The sliced images are displayed as an array of tiled smaller images, but should otherwise have the same appearance as the original (non-sliced) image. AndyM ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-27 19:06 ` Andy Moreton @ 2019-03-27 19:34 ` Andy Moreton 0 siblings, 0 replies; 18+ messages in thread From: Andy Moreton @ 2019-03-27 19:34 UTC (permalink / raw) To: emacs-devel On Wed 27 Mar 2019, Andy Moreton wrote: > On Wed 27 Mar 2019, Eli Zaretskii wrote: > >>> From: Andy Moreton <andrewjmoreton@gmail.com> >>> Date: Wed, 27 Mar 2019 18:35:09 +0000 >>> >>> > It seems to work, but maybe I don't know what and how to check. Can >>> > you show what I should expect to see with and without the :scale >>> > attribute, in "emacs -Q"? >>> >>> I would expect a sliced image to be composed of a grid of tiled images >>> instead of a single image, but to have the same visual appearance as the >>> original image. The w32 code does not get this right. >> >> Did insert-sliced-image ever work on Windows, even before scaling was >> added? This works correctly (without native scaling) on the emacs-26 branch. The following forms result in the same visual appearance in the buffer. (insert-image (create-image "splash.png" nil nil)) (insert-sliced-image (create-image "splash.png" nil nil) nil nil 1 1) (insert-sliced-image (create-image "splash.png" nil nil) nil nil 3 5) AndyM ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-27 18:35 ` Andy Moreton 2019-03-27 18:42 ` Eli Zaretskii @ 2019-03-28 2:26 ` YAMAMOTO Mitsuharu 2019-03-28 16:02 ` Eli Zaretskii 1 sibling, 1 reply; 18+ messages in thread From: YAMAMOTO Mitsuharu @ 2019-03-28 2:26 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1381 bytes --] On Thu, 28 Mar 2019 03:35:09 +0900, Andy Moreton wrote: > > [1 <text/plain (7bit)>] > On Wed 27 Mar 2019, Eli Zaretskii wrote: > > >> Date: Wed, 27 Mar 2019 11:35:26 +0900 > >> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > >> Cc: Alan Third <alan@idiocy.org>, > >> emacs-devel@gnu.org > >> > >> (insert-sliced-image (create-image "splash.png" nil nil :scale 0.5) nil nil 3 5) > >> > >> Actually, I suspect this does not work on W32 because the comparison > >> with the original image size is made for s->slice.width (or height) > >> rather than s->img->width (or height) as I just did for cairo code. > >> Could you check it on W32? > > > > It seems to work, but maybe I don't know what and how to check. Can > > you show what I should expect to see with and without the :scale > > attribute, in "emacs -Q"? > > > > Thanks. > > I would expect a sliced image to be composed of a grid of tiled images > instead of a single image, but to have the same visual appearance as the > original image. The w32 code does not get this right. Thanks for the screenshot. That's what I suspected from the code in w32term.c and the documentation of StretchBlt. Below is the screenshot on Xrender, and it should be the expected result. The cursor is at the last row and the last column of the sliced image. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp [-- Attachment #2: sliced-scaled.png --] [-- Type: image/png, Size: 36671 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-28 2:26 ` YAMAMOTO Mitsuharu @ 2019-03-28 16:02 ` Eli Zaretskii 2019-03-28 18:06 ` Andy Moreton 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-03-28 16:02 UTC (permalink / raw) To: YAMAMOTO Mitsuharu; +Cc: emacs-devel > Date: Thu, 28 Mar 2019 11:26:46 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > > > > It seems to work, but maybe I don't know what and how to check. Can > > > you show what I should expect to see with and without the :scale > > > attribute, in "emacs -Q"? > > > > > > Thanks. > > > > I would expect a sliced image to be composed of a grid of tiled images > > instead of a single image, but to have the same visual appearance as the > > original image. The w32 code does not get this right. > > Thanks for the screenshot. That's what I suspected from the code in > w32term.c and the documentation of StretchBlt. Below is the > screenshot on Xrender, and it should be the expected result. The > cursor is at the last row and the last column of the sliced image. Thanks, I think I fixed this now. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-28 16:02 ` Eli Zaretskii @ 2019-03-28 18:06 ` Andy Moreton 2019-03-28 18:19 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Andy Moreton @ 2019-03-28 18:06 UTC (permalink / raw) To: emacs-devel On Thu 28 Mar 2019, Eli Zaretskii wrote: >> Date: Thu, 28 Mar 2019 11:26:46 +0900 >> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> >> >> > > It seems to work, but maybe I don't know what and how to check. Can >> > > you show what I should expect to see with and without the :scale >> > > attribute, in "emacs -Q"? >> > > >> > > Thanks. >> > >> > I would expect a sliced image to be composed of a grid of tiled images >> > instead of a single image, but to have the same visual appearance as the >> > original image. The w32 code does not get this right. >> >> Thanks for the screenshot. That's what I suspected from the code in >> w32term.c and the documentation of StretchBlt. Below is the >> screenshot on Xrender, and it should be the expected result. The >> cursor is at the last row and the last column of the sliced image. > > Thanks, I think I fixed this now. Confirmed. Should the <kp-subtract> and <kp-add> bindings for `image-decrease-size' and `image-increase-size' be adjusted to handle sliced images ? Also, in w32 builds of emacs-26 'M-X image-rotate' on a (non-sliced) image logs a message: "image--get-imagemagick-and-warn: Cannot rescale images without ImageMagick support", whereas on master it does nothing. Is image rotation expected to work on Windows ? AndyM ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-28 18:06 ` Andy Moreton @ 2019-03-28 18:19 ` Eli Zaretskii 2019-03-28 19:29 ` Andy Moreton 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2019-03-28 18:19 UTC (permalink / raw) To: Andy Moreton; +Cc: emacs-devel > From: Andy Moreton <andrewjmoreton@gmail.com> > Date: Thu, 28 Mar 2019 18:06:17 +0000 > > Should the <kp-subtract> and <kp-add> bindings for `image-decrease-size' > and `image-increase-size' be adjusted to handle sliced images ? It would be nice, yes. > Is image rotation expected to work on Windows ? Not without ImageMagick, no. (And not only on Windows, AFAIK.) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-28 18:19 ` Eli Zaretskii @ 2019-03-28 19:29 ` Andy Moreton 2019-03-28 20:09 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Andy Moreton @ 2019-03-28 19:29 UTC (permalink / raw) To: emacs-devel On Thu 28 Mar 2019, Eli Zaretskii wrote: >> From: Andy Moreton <andrewjmoreton@gmail.com> >> Date: Thu, 28 Mar 2019 18:06:17 +0000 >> >> Should the <kp-subtract> and <kp-add> bindings for `image-decrease-size' >> and `image-increase-size' be adjusted to handle sliced images ? > > It would be nice, yes. A little experimentation shows that changing `image--get-image' as below seems to be sufficient to work for normal and sliced images: (defun image--get-image () "Return the image at point." (let ((image (get-char-property (point) 'display)) result) (when (consp image) (if (eq (car image) 'image) (setq result image) (dolist (x image) (if (eq (car-safe x) 'image) (setq result x))))) (when (null result) (error "No image under point")) result)) >> Is image rotation expected to work on Windows ? > > Not without ImageMagick, no. (And not only on Windows, AFAIK.) ok, but if ImageMagick is not available it used to complain and now does not. It should still report the same error message rather than failing silently. AndyM ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Testing native image scaling 2019-03-28 19:29 ` Andy Moreton @ 2019-03-28 20:09 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2019-03-28 20:09 UTC (permalink / raw) To: Andy Moreton; +Cc: emacs-devel > From: Andy Moreton <andrewjmoreton@gmail.com> > Date: Thu, 28 Mar 2019 19:29:45 +0000 > > >> Should the <kp-subtract> and <kp-add> bindings for `image-decrease-size' > >> and `image-increase-size' be adjusted to handle sliced images ? > > > > It would be nice, yes. > > A little experimentation shows that changing `image--get-image' as below > seems to be sufficient to work for normal and sliced images: > > (defun image--get-image () > "Return the image at point." > (let ((image (get-char-property (point) 'display)) > result) > (when (consp image) > (if (eq (car image) 'image) > (setq result image) > (dolist (x image) > (if (eq (car-safe x) 'image) > (setq result x))))) > (when (null result) > (error "No image under point")) > result)) LGTM, thanks. > >> Is image rotation expected to work on Windows ? > > > > Not without ImageMagick, no. (And not only on Windows, AFAIK.) > > ok, but if ImageMagick is not available it used to complain and now does > not. It should still report the same error message rather than failing > silently. The error message is bogus anyway, as it talks about rescaling, instead of talking about rotating. IOW, it's a bug in the message that should be fixed. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-03-28 20:09 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-01-19 9:31 Testing native image scaling Eli Zaretskii 2019-01-19 21:45 ` Alan Third 2019-01-20 16:05 ` Eli Zaretskii 2019-01-20 19:26 ` Alan Third 2019-01-20 19:41 ` Eli Zaretskii 2019-01-20 20:19 ` Alan Third 2019-03-27 2:35 ` YAMAMOTO Mitsuharu 2019-03-27 17:09 ` Eli Zaretskii 2019-03-27 18:35 ` Andy Moreton 2019-03-27 18:42 ` Eli Zaretskii 2019-03-27 19:06 ` Andy Moreton 2019-03-27 19:34 ` Andy Moreton 2019-03-28 2:26 ` YAMAMOTO Mitsuharu 2019-03-28 16:02 ` Eli Zaretskii 2019-03-28 18:06 ` Andy Moreton 2019-03-28 18:19 ` Eli Zaretskii 2019-03-28 19:29 ` Andy Moreton 2019-03-28 20:09 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).