I think what you are asking for is a built-in image/video viewer/control that just iterates through frames automatically beyond script control. /drawpic's purpose is to display a single image - when it is asked to draw the Nth frame of a GIF/WEBP file, every delta frame preceeding the Nth frame has to be combined up to frame N, depending on key frames, due to the underlying format of GIF/WEBP.
After 30 years, the probability of adding a native GIF control to mIRC is mind-bogglingly close to zero. It's still possible but the odds are so small that we're likely to approach the heat death of the universe, with just enough time left to make a nice cup of tea, before it happens. If you can wait that long, I'll add it to my to-do list :-)
That said, I did some performance profiling and saw a few places where /drawpic can be improved. Changes so far:
1) $pic() was partially reloading images to get width / height / frame / delay values. I have extended the bitmap cache to store these values.
2) The bitmap cache was using too much memory. I have added real-time LZ4 compression/decompression to bitmaps stored in the cache. The performance hit is negligible in the context of timer / script parsing / image display.
3) Because of the LZ4 compression, cache size has been increased from 50 to 500 and GIF/WEBP with mutiple frames are now cached. The LZ4 compression means that the chess gif file example has gone from using 300MB+ when all frames are loaded to just 30MB.
4) I have added a /drawpic -p switch that, when used with -c, will pre-cache all frames by adding them to the bitmap cache on first load as fast as the GIF/WEBP library can manage. This incurs a short delay. But /drawpic will be zippy afterwards.
That's about as much speed as I can squeeze out of this feature, given /drawpic's purpose. See the next beta for these changes.
