Trait gdk_pixbuf::prelude::PixbufAnimationExtManual

source ·

pub trait PixbufAnimationExtManual {
    // Required method
    fn iter(&self, start_time: Option<SystemTime>) -> PixbufAnimationIter;
}

Required Methods§

source

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

Implementors§

source §