Animations are frequently used during screen transitions. A screen transition is a way to move from the visible screen to a new screen which may or may not have common layers. By default, screen transitions can be invoked by using one of the following actions:
- gra.screen
Transition to a new screen immediately
- gra.screen.fade
Fade the new screen into the current screen over time
- gra.screen.path
Slide the new screen in and the old screen out over time, from one of the following directions
Left
Right
Top
Bottom
- gra.screen.scale
Grow the new screen over the current screen
All transition actions, which are time-based, take similar arguments that control the duration of the transition, the rate at which the transitions will occur, the orientation of the transition, and the number of frames that should be used. Using these arguments, the designer can control the user experience (e.g., duration and effects) as well as the overhead incurred on the system (frequency of frame updates).
During a screen transition, four events will be generated to notify the system of the current state. These events are:
- gre.screenshow.pre
This event is generated for the new screen being shown. The event will be generated before the transition starts. This event gives the user a chance to change data via the gra.datachange action or Lua before ther transition content is updated.
- gre.screenhide.pre
This event is generated for the previous screen being hidden. The event will be generated before the transition starts.
- gre.screenshow.post
This event is generated for the new screen being shown. The event will be generated after the transition has completed.
- gre.screenhide.post
This event is generated for the previous screen being hidden. The event will be generated after the transition has completed.
The following illustrates the sequence of events:
The transitions are written such that if graphics hardware layer support is are available, then these layers, assuming they are available for use, will be leveraged to lower the processing overhead for the system during the transition period. Experience has demonstrated that it is possible to achieve smooth transitions at almost no CPU cost when the hardware capabilities can be properly leveraged.