Commit Graph

4 Commits

Author SHA1 Message Date
Emmanuele Bassi
63c7cc0175 [master clock] Handle Timeline::started signal correctly
The "started" signal is sent first after the timeline has been set to the
'running' state. For this reason, checking if the clock has any running
timelines running will always return true in the "started" signal handler:
the timeline that sent the signal is running.

What needs to be checked in the signal handler is if there are any
timelines running other than the one that emitted the ::started signal,
which we know is running anyway.

This prevents frames from being lost at the beginning of an animation when
a timeline is started after a quiescent period.

Fixes bug:

  http://bugzilla.openedhand.com/show_bug.cgi?id=1617

Signed-off-by: Jonas Bonn <jonas@southpole.se>
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
2009-05-29 15:13:55 +01:00
Emmanuele Bassi
86bc31bd55 [clock] Rework the master clock
The master clock is currently advanced using a frame source driven
by the default frame rate. This breaks the sync to vblank because
the vblanking rate could be different than 60 Hz -- or it might be
completely disabled (e.g. with CLUTTER_VBLANK=none).

We should be using the main loop to check if we have timelines
playing, and if so queue a redraw on the stages we own.

We should also prepare the subsequent frame at the end of the redraw
process, so if there are new redraw we will have the scene already
in place.

This makes Clutter redraw at the maximum frame rate, which is
limited by the vblanking frequency.
2009-05-07 19:25:24 +01:00
Emmanuele Bassi
5be29cf9bc [timeline] Expose the msec advancement
The method of ClutterTimeline that advances the timeline by a
delta (in millisecond) is going to be useful for testing the
timeline's behaviour -- and unbreak the timeline test suite that
was broken by the MasterClock merge.
2009-05-01 15:05:51 +01:00
Emmanuele Bassi
678f99677f Use a single master "clock" to drive timelines
Currently, all timelines install a timeout inside the TimeoutPool
they share. Every time the main loop spins, all the timeouts are
updated. This, in turn, will usually lead to redraws being queued
on the stages.

This behaviour leads to the potential starvation of timelines and
to excessive redraws.

One lesson learned from the games developers is that the scenegraph
should be prepared in its entirety before the GL paint sequence is
initiated. This means making sure that every ::new-frame signal
handler is called before clutter_redraw() is invoked.

In order to do so a TimeoutPool is not enough: we need a master
clock. The clock will be responsible for advancing all the active
timelines created inside a scene, but only when the stage is
being redrawn.

The sequence is:

  + queue_redraw() is invoked on an actor and bubbles up
    to the stage

  + if no redraw() has already been scheduled, install an
    idle handler with a known priority

  + inside the idle handler:

    - advance the master clock, which will in turn advance
      every playing timeline by the amount of milliseconds
      elapsed since the last redraw; this will make every
      playing timeline emit the ::new-frame signal

    - queue a relayout

    - call the redraw() method of the backend

This way we trade multiple timeouts with a single frame source
that only runs if a timeline is playing and queues redraws on
the various stages.
2009-04-24 15:28:15 +01:00