Previously I wrote: > All that's left then, is to actually decode all the > frames when loading the image and to properly free > the memory (as needed) on object destruction.
This seems slightly more involved, as the current GIF loader loops and scans to the first frame image data, then proceeds to load and convert that image data, after which the file is closed. In other words, the code is not currently suitable for/capable of loading multiple frames at all. Also, the whole loader is inside one giant constructor method. I guess I'll try to refactor it a bit and move some code into functions, before moving the image loading+ converting into the frame scanning loop. By the way, as one could consider GIF animations part of the standard, I think it makes more sense to extend the current GIF class with that functionality, rather than to derive it into an AnimatedGIF sub-class. Would there be any chance this functionality makes it into FLTK? If so, are there any specific requirements to the code that I should be aware of? (Of course one way or another I'll make the code available online again, as I've done before with Fl_Image_Button and friends!) Best, Marc _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
