Re: Animations with image size matching output resolution

[Ethan M. <merritt@u.washington.edu>]

On Friday 30 December 2005 05:34 am, Daniel J Sebald wrote:
>
>  /* FIXME - 
>  /* Also, the very last frame should be followed by a call to   
> /* gdImageGifAnimEnd(gpoutfile)  
> /* although in practice it doesn't seem to matter. */							*/ 
>
> Thanks for leaving that message.  I forced a
> gdImageGifAnimEnd(gpoutfile) at the end of my twentieth image and
> sure enough that makes the animated GIF work in gthumb.  So, I think
> this "it doesn't seem to matter" is not a correct statement.

Please try the attached patchset.
It fixes that issue and a number of other minor bugs like not reporting
the optimization setting when the terminal is in animation mode.

> I see why the comment is there; because the closing of the file is
> done in term.c.  Now I think there should be, and I'm surprised there
> already isn't, a terminal function for finishing a file, e.g.,
>
> <term>_finishfile
> <term>_wrapup
>
> I would think other formats that use compression and such might need
> to also have a wrap-up routine.

I have added a terminal flag  TERM_CALL_ON_CLOSE
that a terminal can set if it wants to be called before the output file
is closed.  If it is set, then the core code will call back via
term->layer(TERM_LAYER_END_MULTI_FRAME_SEQUENCE).

It may be worth creating a separate terminal entry point, as you say.
On the other hand I think that this is in fact a "layer" boundary of a 
sort.  I could imagine calling it after a sequence of images in a
postscript output file, for instance, to cause the driver to emit an
accumulated BoundingBox and other per-document meta information.

It's tricky, because the terminal type itself may have changed by the
time the output file is closed.  You would have to call the *previous*
driver, which is dicey at best.  I think this will remain a case where an
explicit "{un}set output" is needed to guarantee that the animation
file is correctly terminated.

> Note that running these gnuplot GIF animations through gifsicle
> compresses them by a factor of three... don't think that is our
> problem.

That may be due to the optimization flag not being initialized properly.
Hopefully this is fixed in the attached patch. At the least you can now
see whether it is set or not by using "show term".

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA