gdk_pixbuf::prelude

Trait PixbufAnimationExtManual

Source
pub trait PixbufAnimationExtManual:
    Sealed
    + IsA<PixbufAnimation>
    + 'static {
    // Provided method
    fn iter(&self, start_time: Option<SystemTime>) -> PixbufAnimationIter { ... }
}

Provided 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

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.

Implementors§