After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 358109 - Provide more info for animation players
Provide more info for animation players
Status: RESOLVED OBSOLETE
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other All
: Normal enhancement
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
Depends on:
Blocks:
 
 
Reported: 2006-09-28 09:49 UTC by Francesco Montorsi
Modified: 2018-05-22 13:04 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
the patch (43.17 KB, patch)
2006-09-28 09:49 UTC, Francesco Montorsi
rejected Details | Review

Description Francesco Montorsi 2006-09-28 09:49:17 UTC
For a number of different uses of GdkPixbufAnimation API, it's fundamental to know the number of frames available inside an animation object and also the frame associated with an animation iter.

The attached patch adds the following functions:

gint gdk_pixbuf_animation_get_frame_count(GdkPixbufAnimation *animation);
gint gdk_pixbuf_animation_iter_get_current_frame(GdkPixbufAnimationIter *iter);

SOME NOTES ABOUT THE PATCH:
 1) I've seen that sometimes "int" is used and other times "gint" is used.
    I've used "int" but maybe it would be more correct to use "gint" ?

 2) inside gdk_pixbuf_animation_iter_get_current_frame() the g_return_val_if_fail returns -1 in case it fails. Maybe it should return zero?

 3) I've not used tabs in my patch, sorry; however I think there should be some tool to "tabify" the patch before applying it, isn't it ?
Comment 1 Francesco Montorsi 2006-09-28 09:49:57 UTC
Created attachment 73544 [details] [review]
the patch

2006-09-28  Francesco Montorsi  <fr_m@hotmail.com>

    * gdk-pixbuf-animation.c:
    * gdk-pixbuf-animation.h:
    * gdk-pixbuf-simple-anim.c:
    * io-ani-animation.c:
    * io-gif-animation.c: Added the
    gdk_pixbuf_animation_get_frame_count and
    gdk_pixbuf_animation_iter_get_current_frame
    functions
Comment 2 Matthias Clasen 2006-10-02 03:45:39 UTC
The animation iter api is intentionally abstract. 
It allows for animations that are not frame-based at all.
Therefore it would be problematic to add functions like the proposed ones.
Can you explain what use your application would make of this information ?
Comment 3 Francesco Montorsi 2006-10-02 15:36:24 UTC
>It allows for animations that are not frame-based at all.
I imagine you refer to future animation formats like e.g. "animated SVG", right?


>Can you explain what use your application would make of this information ?

Sure: I need to play an animation without looping it. 

Currently that's impossible (right?) because gdk_pixbuf_animation_iter_advance() automatically loops the animation if you pass a time value > animation total time.
Since the API doesn't tell me which is the time of the total animation, I can't say to GdkPixbuf that the time has been "frozen" at the total time of the animation. Also, it doesn't let me know which frame I'm currently displaying so I'm a bit lost...

Also, the animation can be user-chosen at runtime (in my program) and thus I cannot just create and use an animation with an infinite delay for the last frame.

Another use case for these functions would be to show an animation when doing some long process meanwhile. Not a throbber but rather an animation where each frame must be shown for an exact percent of work done.
E.g. frame 1 must be shown at 20%, frame 2 at 40%, last frame at 100%.
If you don't know the frame count of the animation to play in this way, that's impossible (unless you know it at compile-time but that's not a good solution IMO)...

====

About the frame concept: isn't it already (at least partially) implied by gdkpixbuf API and in particular by gdk_pixbuf_animation_iter_advance()/gdk_pixbuf_animation_iter_get_delay_time() ?
gdk_pixbuf_animation_iter_advance() returns TRUE when you need to update the GdkPixbuf to show to the user. I.e. when a new frame should be displayed....

Also, I have some troubles to imagine animations without frames :D
i.e. even animated vector graphics where the anim just says you: A object must go from point X to Y in time Z, you need to decompose that motion in discrete frames using some "motion fluency" parameter, isn't it? you cannot update infinite times the screen... or return zero from gdk_pixbuf_animation_iter_get_delay_time(), can you ?

Even if for those formats the functions implemented by this patch reveal to be unappropriate, maybe they could be implemented to return "-1" for those formats?

Thanks and keep up the good work!

Comment 4 Matthias Clasen 2006-10-03 15:27:06 UTC
>Sure: I need to play an animation without looping it. 
>
>Currently that's impossible (right?) because
>gdk_pixbuf_animation_iter_advance() automatically loops the animation if you
>pass a time value > animation total time.

I don't think there is an automatic looping. We do respect the looping 
information in gif animations, and there is admittedly not api currently
to override or influence that.

>Since the API doesn't tell me which is the time of the total animation, I can't
>say to GdkPixbuf that the time has been "frozen" at the total time of the
>animation. Also, it doesn't let me know which frame I'm currently displaying so
>I'm a bit lost...

Adding a function to obtain the total time of the animation might be doable.

Comment 5 Francesco Montorsi 2006-10-03 20:49:23 UTC
>Adding a function to obtain the total time of the animation might be doable.
that would help but what about the _get_frame_count() and _get_current_frame() functions?

Comment 6 Sven Herzberg 2008-08-11 20:49:16 UTC
What about introducing GdkPixbufFrameAnimation interface so apps can check GDK_IS_PIXBUF_FRAME_ANIMATION() before trying to call into these?

This would have to be applied to the APNG loader from bug 151281 as well.
Comment 7 Bastien Nocera 2014-10-22 12:09:27 UTC
Review of attachment 73544 [details] [review]:

As per comment 2.
Comment 8 GNOME Infrastructure Team 2018-05-22 13:04:41 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/9.