A #GdkFrameClock tells the application when to update and repaint a
window. This may be synced to the vertical refresh rate of the
monitor, for example. Even when the frame clock uses a simple timer
rather than a hardware-based vertical sync, the frame clock helps
because it ensures everything paints at the same time (reducing the
total number of frames). The frame clock can also automatically
stop painting when it knows the frames will not be visible, or
scale back animation framerates.
#GdkFrameClock is designed to be compatible with an OpenGL-based
implementation or with mozRequestAnimationFrame in Firefox,
for example.
A frame clock is idle until someone requests a frame with
gdk.frame_clock.FrameClock.requestPhase. At some later point that makes
sense for the synchronization being implemented, the clock will
process a frame and emit signals for each phase that has been
requested. (See the signals of the #GdkFrameClock class for
documentation of the phases. gdk.types.FrameClockPhase.Update and the
#GdkFrameClock::update signal are most interesting for application
writers, and are used to update the animations, using the frame time
given by gdk.frame_clock.FrameClock.getFrameTime.
The frame time is reported in microseconds and generally in the same
timescale as glib.global.getMonotonicTime, however, it is not the same
as glib.global.getMonotonicTime. The frame time does not advance during
the time a frame is being painted, and outside of a frame, an attempt
is made so that all calls to gdk.frame_clock.FrameClock.getFrameTime that
are called at a “similar” time get the same value. This means that
if different animations are timed by looking at the difference in
time between an initial value from gdk.frame_clock.FrameClock.getFrameTime
and the value inside the #GdkFrameClock::update signal of the clock,
they will stay exactly synchronized.
A #GdkFrameClock tells the application when to update and repaint a window. This may be synced to the vertical refresh rate of the monitor, for example. Even when the frame clock uses a simple timer rather than a hardware-based vertical sync, the frame clock helps because it ensures everything paints at the same time (reducing the total number of frames). The frame clock can also automatically stop painting when it knows the frames will not be visible, or scale back animation framerates.
#GdkFrameClock is designed to be compatible with an OpenGL-based implementation or with mozRequestAnimationFrame in Firefox, for example.
A frame clock is idle until someone requests a frame with gdk.frame_clock.FrameClock.requestPhase. At some later point that makes sense for the synchronization being implemented, the clock will process a frame and emit signals for each phase that has been requested. (See the signals of the #GdkFrameClock class for documentation of the phases. gdk.types.FrameClockPhase.Update and the #GdkFrameClock::update signal are most interesting for application writers, and are used to update the animations, using the frame time given by gdk.frame_clock.FrameClock.getFrameTime.
The frame time is reported in microseconds and generally in the same timescale as glib.global.getMonotonicTime, however, it is not the same as glib.global.getMonotonicTime. The frame time does not advance during the time a frame is being painted, and outside of a frame, an attempt is made so that all calls to gdk.frame_clock.FrameClock.getFrameTime that are called at a “similar” time get the same value. This means that if different animations are timed by looking at the difference in time between an initial value from gdk.frame_clock.FrameClock.getFrameTime and the value inside the #GdkFrameClock::update signal of the clock, they will stay exactly synchronized.