pub trait PixbufAnimationExtManual: IsA<PixbufAnimation> + 'static {
// Provided method
fn iter(&self, start_time: Option<SystemTime>) -> PixbufAnimationIter { ... }
}Provided Methods§
Sourcefn iter(&self, start_time: Option<SystemTime>) -> PixbufAnimationIter
fn iter(&self, start_time: Option<SystemTime>) -> PixbufAnimationIter
Get an iterator for displaying an animation.
The iterator provides the frames that should be displayed at a given time.
@start_time would normally come from g_get_current_time(), and marks the beginning of animation playback. After creating an iterator, you should immediately display the pixbuf returned by gdk_pixbuf_animation_iter_get_pixbuf(). Then, you should install a timeout (with g_timeout_add()) or by some other mechanism ensure that you’ll update the image after gdk_pixbuf_animation_iter_get_delay_time() milliseconds. Each time the image is updated, you should reinstall the timeout with the new, possibly-changed delay time.
As a shortcut, if @start_time is NULL, the result of
g_get_current_time() will be used automatically.
To update the image (i.e. possibly change the result of gdk_pixbuf_animation_iter_get_pixbuf() to a new frame of the animation), call gdk_pixbuf_animation_iter_advance().
If you’re using #GdkPixbufLoader, in addition to updating the image
after the delay time, you should also update it whenever you
receive the area_updated signal and
gdk_pixbuf_animation_iter_on_currently_loading_frame() returns
TRUE. In this case, the frame currently being fed into the loader
has received new data, so needs to be refreshed. The delay time for
a frame may also be modified after an area_updated signal, for
example if the delay time for a frame is encoded in the data after
the frame itself. So your timeout should be reinstalled after any
area_updated signal.
A delay time of -1 is possible, indicating “infinite”.
§start_time
time when the animation starts playing
§Returns
an iterator to move over the animation
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.