-
- would normally come from
+
+ would normally come from
g_get_current_time() (FIXME: this function isn't bound into C#;
this needs a look), and
marks the beginning of animation playback. After creating an
iterator, you should immediately display the pixbuf returned by
- . Then, you should install a
+ . Then, you should install a
timeout (with g_timeout_add() (FIXME)) or by some other mechanism ensure
that you'll update the image after
- milliseconds. Each time
+ milliseconds. Each time
the image is updated, you should reinstall the timeout with the new,
possibly-changed delay time.
-
- As a shortcut, if is , the result of
+
+
+ As a shortcut, if is , 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 , in addition
+ If you're using , in addition
to updating the image
after the delay time, you should also update it whenever you
receive the area_updated signal and
- returns
+ 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
- signal, for
+ 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
- signal.
-
+ signal.
+
+
A delay time of -1 is possible, indicating "infinite."
-
+
-
- would normally come from g_get_current_time(), and
+
+ would normally come from g_get_current_time(), and
must be greater than or equal to the time passed to
- , and must increase or remain
+ , and must increase or remain
unchanged each time this method is
called. That is, you can't go backward in time; animations only
play forward.
-
- As a shortcut, pass for the current time and g_get_current_time()
+
+
+ As a shortcut, pass for the current time and g_get_current_time()
will be invoked on your behalf. So you only need to explicitly pass
- if you're doing something odd like playing the animation
+ if you're doing something odd like playing the animation
at double speed.
-
+
+
If this method returns false, there's no need to update the animation
display, assuming the display had been rendered prior to advancing;
if true, you need to call
- and update the
+ and update the
display with the new pixbuf.
-
+
- should be the colormap for the graphics context and
- drawable you're using to draw. If you're drawing to a ,
- call .
-
- should have its red, green, and blue fields initialized;
- this method will fill in 's pixel field with the best
+
+ should be the colormap for the graphics context and
+ drawable you're using to draw. If you're drawing to a ,
+ call .
+
+
+ should have its red, green, and blue fields initialized;
+ this method will fill in 's pixel field with the best
matching pixel from a color cube. The color is then ready to be
- used for drawing, e.g. you can call which
+ used for drawing, e.g. you can call which
expects "pixel" to be initialized.
-
+
+
In many cases, you can avoid this whole issue by setting
- or , which
+ or , which
do not expect "pixel" to be initialized in advance. If you use those
mutators, there's no need for calling this method.
-
+
a
a
-
+