Posted By:
Finlay_McWalter
Posted On:
Tuesday, June 12, 2001 05:34 PM
This is a bit of a hack, but it should work.
When you're displaying the image, you'll probably be monitoring its loading with an ImageObserver - this will give you a FRAMEBITS callback each time a GIF frame is ready for display. Normally you'd then draw the image onto whatever control (Canvas, usually) that you want it displayed on. In your case, if you're in "pause" mode then you just ignore the FRAMEBITS callback and don't do a paint.
As I said, this is a hack, as it has the
following drawbacks:
- if you're forced by the Window Manager to repaint the Canvas, then you'll draw a new GIF frame, which won't
match what's already there - so if the repaint is partial then you'll see a
"torn" image (parts of one frame and parts of another). To fix this, keep a valid frame of the image (generally the last one) in an offscreen image, and use
that to service repaint requests.
- the animation continues in the background, so when you resume the drawing you will not pick up where you left off. There is no API to stop the AWT internal thread that's doing this, so you have two (horrible) solutions:
- make an offscreen image each time a FRAMEBITS is done. This is finite, providing the GIF doesn't cycle.
- somehow find the Thread that's doing the decoding (by walking around the ThreadGroup heirarchy in a very non-portable way) and then calling the deprecated method Thread.suspend() on it. This is a very bad thing to do :)
