On Sat, Dec 08, 2018 at 01:24:13PM -0800, Paul Eggert wrote:
> Alan Third wrote:
> > In case anyone cares, I looked into this and XRender would do the
> > trick. I had a look at how to go about it, but as usual with X stuff
> > it looks a fair bit more complicated than with NS (and Windows), and I
> > don’t have a good X environment to play about in.
> 
> I have an X environment (and a Wayland one too); could you please post any
> code you wrote, if you think the idea is worth a try?

The attached appears to somewhat work (at least on my incredibly slow
atom laptop). It’s not really workable in its current form. It’s slow
because it has to load the image each time due to the way image
caching works. I think there are a number of other places we may need
to replace XCopyArea. It doesn’t handle the case where XRender isn’t
available.

Nor with animated gifs in X. They’re fine in NS... ¯\_(ツ)_/¯

It also doesn’t play nice with imagemagick, so make sure to build
--without-imagemagick.

If we want to go with this method I’ll have to rewrite some of the
image handling code. At the moment we create one ‘struct image’ per
lisp image spec, and store the image in the image cache, but this
means if the same image is displayed twice at two different sizes we
load it twice and store it twice. OTOH, it’s the resized version
that’s stored, so that might save memory if we assume people are
mostly shrinking images.

What I’ve done in the attached would work better if we only loaded the
image once and didn’t tie it to an image spec, so we’d only keep one
(full size) copy in memory, and just resize it on demand. I’m unsure
how we’d go about detangling the image data from the image spec.

It may be possible to use XRender (and NSImage resizing) when we load
the image, and therefore work in the same way we do at the moment.
-- 
Alan Third