bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#38187: 27.0.50; No mouse-wheel scaling on images


From: Eli Zaretskii
Subject: bug#38187: 27.0.50; No mouse-wheel scaling on images
Date: Fri, 22 Nov 2019 15:26:42 +0200

> Date: Fri, 22 Nov 2019 10:33:00 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: larsi@gnus.org, 38187@debbugs.gnu.org, stefan@marxist.se,
>       juri@linkov.net
> 
> > > A simple ‘solution’ to the mousewheel scaling issue would be to
> > > explicitly flush the old image from the cache on each change. I think
> > > that’s what image mode does when you zoom.
> > 
> > image-mode can do that when it knows the scaled image will replace the
> > previous one, yes.  (We will need to add an API for that, I think.)
> > But that's not cache eviction, that's application being smarter about
> > the "garbage" it produces.
> 
> Actually, now I look at the code, when an image is resized using the
> mousewheel the previous image should already be flushed.
> 
> In image.el we have this function:
> 
> (defun image--get-imagemagick-and-warn ()
>   (unless (or (fboundp 'imagemagick-types) (image-transforms-p))
>     (error "Cannot rescale images on this terminal"))
>   (let ((image (image--get-image)))
>     (image-flush image)    ;;; <<---------------
>     (when (and (fboundp 'imagemagick-types)
>                (not (image-transforms-p)))
>       (plist-put (cdr image) :type 'imagemagick))
>     image))
> 
> which is called every time an image is resized. So perhaps I
> misunderstand what image-flush does, or we do have a memory leak?

Strange indeed.  I suggest to step in a debugger through this and
other relevant code in this scenario, and see what happens there.  I'd
be surprised to know that we have a memory leak in this area.





reply via email to

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