Re: GdkPixbufAnimation

[Helmethead <hoshem mel comcen com au>]

While on the subject, you should try using the GdkPixbufLoader. I haven't been able to get my head very well around the problems and come up with a solution..

I vaguely remember some things:
- Biggest problem is that area_prepared doesn't pass in the new pixbuf as documented, making the api unusable
- The api is awkward and crappy to implement. It seems designed for applications that don't know whether they want a pixbuf or an animation, which is a bit silly.
- It requires that the first frame of an animation be used as the "static image" if that's what the app wants. Maybe this is what you want though, I don't know. 

The loader api also depends on the GtkPixbufFrame style of doing things, if you want to abolish it you need to rework the loader I think.

On Thu, Apr 26, 2001 at 08:12:44PM -0400, Havoc Pennington wrote:
> 
> Hi,
> 
> Trying to implement animation support for GtkImage, discovered that 
> GdkPixbufAnimation has some issues.
> 
> Minor problem:
> 
>  gdk_pixbuf_frame_get_delay_time() is documented to return 
>  milliseconds, which would make sense, but actually it 
>  returns hundredths. I think this is an implementation bug
>  not a docs bug. But e.g. GtkHTML already works around it 
>  by doing a * 10 on the return value. Can't be fixed
>  in stable. :-(
> 
> Large meta-problem:
> 
>  The API is too GIF-specific. I just implemented a better-abstracted
>  API:
> 
> GdkPixbufAnimationIter *gdk_pixbuf_animation_get_iter            (GdkPixbufAnimation     *animation);
> void                    gdk_pixbuf_animation_iter_free           (GdkPixbufAnimationIter *iter);
> gboolean                gdk_pixbuf_animation_iter_next           (GdkPixbufAnimationIter *iter);
> int                     gdk_pixbuf_animation_iter_get_delay_time (GdkPixbufAnimationIter *iter);
> GdkPixbuf              *gdk_pixbuf_animation_iter_get_pixbuf     (GdkPixbufAnimationIter *iter);
> 
>  i.e. for each step you display the returned pixbuf, wait the delay
>  time, call _next(), display the next pixbuf.
> 
>  The iterator may continue infinitely, or _next() may eventually
>  return FALSE.
> 
>  This takes the frame actions, etc. into account, and just maintains 
>  one or two pixbufs of the "current graphic to display" with 
>  frames composited appropriately.
> 
> API bug:
> 
>  You can't actually render GIFs properly, especially if you read the docs.
> 
>  GtkFrameAction is supposed to correspond to the GIF actions:
>   a) leave graphic as it was with this frame rendered
>   b) restore area used by this frame to the background color
>   c) restore area used by this frame to what was in that area previously
> 
>  However the GtkFrameAction docs say:
>  
>   GDK_PIXBUF_FRAME_RETAIN The previous image should remain displayed,
>    and will potentially be occluded by the new frame.
> 
>   GDK_PIXBUF_FRAME_DISPOSE The animation will be reverted to the state
>    before the frame was shown.
> 
>   GDK_PIXBUF_FRAME_REVERT The animation will be reverted to the first frame.
> 
>  These are reported for a), b), c) respectively.
> 
>  So the documented behavior of _REVERT does not exist in GIF, the
>  documented behavior of _DISPOSE should be done when io-gif actually 
>  reports _REVERT, and the correct GIF behavior b) is not possible 
>  to implement because you can't get the background color from the 
>  GIF file.
> 
> Suggested course of action in unstable branch:
> 
>  Add the iterator API, so we can support MNG and stuff, and so 
>  using the API isn't insanely difficult
> 
>  Deprecate the rest of the API; lose the whole GdkPixbufFrame 
>  deal. Actually, consider just removing this API, because
>  any code using it is broken, the API is not usable.
> 
>  Fix the GIF loader to return the background color and other 
>  necessary info, but this is all internal, we wouldn't 
>  expose frames, bg color, etc. via the API.
> 
> Suggested course of action in stable branch:
>  
>  I believe we are fucked, but maybe someone has an idea.
> 
> Havoc
> 
> 
>  
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list