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

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]