Re: GDI+ take 3

[Alan Third <alan@idiocy.org>]

On Tue, Apr 21, 2020 at 09:34:56PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 21 Apr 2020 19:17:34 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: emacs-devel@gnu.org
> > 
> > I agree with you, though, that fixing this particular performance
> > problem would require us to rethink how we load and cache images.
> 
> I don't think our image caching mechanism was designed to show
> animations.  It was designed to show a small number of static images
> within mostly-textual content.

I’ve been thinking a little about if it’s possible to move image
loading into modules to be loaded at runtime, and one of the ideas I
had to support that may be helpful here. I don’t know too much about
Emacs Lisp’s internals, so feel free to shoot this idea down.

I believe we could add a new method of defining images which would be,
in effect, a pointer to a decoded image. Perhaps a system dependent
format, like pixmap on X, or an NSImage object on macOS, but it could
easily be some system independent format we devise ourselves.

We would have to provide a function (or perhaps modules could provide
it) where we pass in a filename, or data, and get back this pointer.
The function could also take a range of frame numbers, and return a
list of image pointers all decoded at once.

When displaying the image instead of passing a filename or data to
create-image, we pass in the image pointer, and everything should work
more or less the same from there.

We would have to rewrite how animations are displayed to update the
image from a list of image pointers instead of incrementing the frame
count.

The image pointer would, presumably, be subject to garbage collection,
so we may have to be able to clear any related images from the image
cache when it’s garbage collected. I don’t know how practical this is.

-- 
Alan Third