Gif Readers and Probes
Last updated at 2:23 am UTC on 15 March 2009
Squeak needs a better way to read and display gifs.
The gif spec is well documented. It can be used to describe how a gif reader needs to be written.
Morphics current way of displaying animated gifs ignores some of the details of the spec and gets other parts of it wrong. So some repair is in order.
The gif spec can be read here: http://www.w3.org/Graphics/GIF/spec-gif89a.txt
Currently (3.10.2 and before) Morphic reads animated gifs but ignores the virtual screen dimension a form is produced for each image block. The offset for the image is stored in the form but not taken into account
by the AnimatedImageMorph. The delays are stored in an array but that array is generally ignored and a fixed delay
used by the morph.
The graphic control can suggest a disposal option for the image after it has been displayed. The important distinction is whether the image is kept up or removed. Currently this is ignored and the AnimatedImageMorph just removes one image to display then next.
Finally there is a bug in the reader itself that makes the reader get confused if the number of bits per pixel changes from one morph to another. This proved to be the motivating factor in the latest round of repairs.
The bug itself has been found and reported on Mantis.
What I am proposing is to create an AnimeMorph to replace the current AnimatedImageMorph.
The base morph would be the size of the virtual screen and have step methods to do the animation
of its submorphs. The images of the gif would each be represented by a separate submorph.
Each submorph would have
- its own stepTime for the delay before it is shown.
- a way to honor its disposal method when sent a windup message.
- a position within the AnimeMorph consistent with the offset of its image.
- a submorph index s.t. younger images will overlay older images.
The interesting thing about doing things this way is that it becomes extremely simple to build
animated morphs. You can embed any morph in the AnimeMorph at any position.
The morph does not have to be an image morph. As long as it can respond to stepTime and windup.
It can be animated.
All objects respond to stepTime already. So it is only necessary to add a Morph>>windup to make animation work. By adding a backup method Object>#stepTime: , we can create sliders to control the speed of animation.