1: If you don't have the "workaround", imlib2 will grab the X window content, blend the image onto the grabbed copy, and then write the blended result back.
If you do have the workaround you will do the blending in a forward flow not involving the X server and just write the result.
So wrt. X operations the first is like read-modify-write whereas the second is just write.
Non-alpha images don't need a blend so you can just do a write.
Since X-operations are relatively expensive (and particularly reads cause round-trip delays) it is always important to avoid them when possible.

2,3: Hmm.. I don't see such numbers. From a quick test (using nsxiv from git) I find roughly x2 due to scaling and almost nothing due to aa.
I'm not entirely confident in those numbers but that's what I see just now doing a trivial time measurement around the rendering in img_render().
This is on x86_64 with asm mmx functions. Tested with a few random alpha and non-alpa images.

Multi-frame images:
Well, I have considered if it would be useful to add functions to query the number of images (frames?) in (multi-frame) images and fetch a specific one.
But I haven't had specific use for it myself.
For testing purposes I have in the ico and webp loaders implemented the possibility to specify a specific image "index" by means of the "key" function, that is, e.g. appending ":6" to the file name should select the 6'th frame.
I don't consider that a proper API though.

Thanks for the X explanation, it makes sense.

Interesting that your measurements aren't lining up with mine. I originally investigated this because I saw that there's a good amount of time being spent on __imlib_ScaleAARGBA() on perf report. Anyways, I'll try to get some more people to test it, could be something due to my system/environment.

Function to query and get a specific image would be useful indeed. I wasn't aware of the ":n" trick, I'll play around with it. Is there any function to query the "frame delay"?

As far as I'm seeing, being able to load a specific image and query it's delay should be enough for us to get image animation going. It seems to be a pretty popular request too (I saw feature requests for animated images on feh as well, but was shut down as wontfix since Imlib2 doesn't support it). It could also prevent a lot of duplicated work, currently there's a good amount of work duplication between the Imlib2's gif loader and sxiv gif loader.

Hi, the "key" thing on animated webp was always resulting in selecting the last frame for me. I've attached a patch fixing it. (Not sure what the workflow here is for patches, sorry).

Pushed.
Yeah, it looks like my uninitialized iter usually had num_frames set so some large value so it seemed to work.
I' m fine with patches like this or sent to me directly, kim@woelders.dk.
Thanks :)

In T8969#156204, @kwo wrote:

I have added some support for multi-frame images. webp and gif (and ico) loaders now support loading multi-frame images. Example usage in imlib2_view (somewhat conveluted, mostly for debug).

This looks pretty nice. Thank you.

I'll close this issue now as there has been no follow-up on the performance issues.

Fair. I've asked on the matrix room for people test it out, but unfortunately no one seemed interested. If I can narrow down that the problem is indeed coming from imlib2 then I will reopen this with more detailed info.