Hello all, Thank you for all the insights.
Ian, Fl_Help_View most definitely uses Fl_Shared_Image. I have yet to fully comprehend what Fl_Shared_Image actually does- I see it's some sort of cache, but its name also seems to imply that memory is allocated only once if an image is used multiple times or something? Chris: >> First of all- I can't call redraw() from Fl_GIF_Image- >> this method does not seem to be available for any of its >> parent classes, > > This is certainly THE major problem. > The only way I see to trigger a redraw > from a class not inherited from Fl_Widget > is using Fl::redraw(). But this redraws all > the widgets of the application... Yes, As much as I'd like Fl_GIF_Image to be fully self-contained, for a generic solution that doesn't sound acceptable. Also, simply redrawing a button containing the Fl_GIF_Image did not actually update the frame, so it might not even work. It's very easy to give it a try though. > The problem is within Fl_Pixmap class draw() > method: The offscreen buffer is only written > to once (with the first frame), then always > just copied from that buffer. So setting data() > pointer has no effect. It is easy to change > though, then the animation works. I'll have to look into that then. > I think you will need to write your own draw() > method for the Fl_GIF_Image class sooener or > later, because you must also handle the possibly > different x/y offsets of individual gif frames. I've given that some thought, and I'm not sure if the X/Y offsets should not simply be treated as part of the compression/decoding scheme. Dealing with the X/Y offsets in a draw() function (to only update the changed part of the picture) will give some problems if a frame needed to be dropped, or may leave damaged parts of the image damaged, or (to work around these problems) will require decoding more than one frame- which we might as well do while the image data is being loaded from file. The benefits are that the draw() function can remain simple and generic, image quality won't suffer if frames are dropped (or when things are drawn over the frame) and the decoding only needs to be done once, while loading- rather than causing a recurring extra load while animating. The downside is that in some cases (not always) it might result in a bit higher memory footprint for animated GIFs. I think this is acceptable; The image is decompressed during the loading phase anyhow. If the memory footprint really is an issue, maybe one should not use animated GIF images in the first place. Albrecht: > The offscreen buffer is only written to once > (with the first frame), then always just copied > from that buffer. So setting data() pointer has > no effect. It is easy to change though, then the > animation works. > I think that you should call [Fl_Pixmap:: ] > uncache() to reset the cached image whenever you > change the data pointer. It may well be that that's the actual cause of the trouble. In any case, I'll get back to this soon and will let you all know how it goes! Best, Marc _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
