Concept and Use Cases

Transitions Concept

Generally speaking, the concept of "transition" indicates the edge between two different states. In our case, the very notion of transition indicates the visual dynamics involved in displaying the content of a scene which is replacing another scene. Using a transition provides continuity so that the scene change is not quite so abrupt.

The rules editor panel allows the definition of transitions on a per scene basis and test these transitions directly in SceneComposer's display preview. The designer can use the editor to set the transitions to (="Destination") or from a scene (="Source") just by selecting effects (="Transition Types") on the scene list.

Types of Transitions

The rules editor features a toolbox where both "built in" transitions and "custom" transitions are available, a configurable default behavior, two scrollable lists ("Source" and "Destination") of all scenes in the solution, a "Variant" scrollable list, and a properties panel. To create a rule it is mandatory, first, to select the source and the destination, a specific type of that transition and, finally, to set the transition properties. After all these steps are done, the transition can be executed in the "Transition Execution" panel.

The available simple transitions are the following:

The available combined transitions are the following:

Transition Type Animation

The Transitions framework has a special build-in transition type – Animation. By using this transition type, it is possible to trigger animations or group animations within transitions. The Variant holds three Additional optional parameters:

The animation specific parameters can be specified in the properties panel once the corresponding transition type has been selected:

The animations can be triggered through a Request using the corresponding Variant name.

Sequential Execution of Transitions

The Transitions framework furthermore allows the sequential execution of transition fragments. One or multiple activation or deactivation fragments can be executed before or after fragments of the respective opposite fragment type. Therefore, the rules editor offers the option to set the "Activation" and "Deactivation" strategy.

The strategy types are:

The combination of "Early" and "Late" will cause a sequential execution of the involved transition fragments. Any other combination results in a default transition behavior. "Early" fragments are executed before "Late" fragments.

For example: Scene_1 has a rule to perform a transition with a Fade to Scene_2. Scene_2 (activation fragment) should fade in completely before Scene_1 (deactivation fragment) begins to fade out. For this rule, the "Activation" strategy would be "Early" and the "Deactivation" strategy would be "Late". The opposite result can be achieved by swapping the fragments' strategy.

However, it is important to note that multiple "Early" or "Late" fragments will be executed in parallel and that "Late" fragments will only be executed once all "Early" fragments have finished first.

Early and Late Transition Delays

Sequential Transitions furthermore offer the possibility to customize the moment, when "Late" fragments are executed after the "Early" fragments are finished. Next to the strategy type, a delay value (in milliseconds) can be set for "Activation" and "Deactivation" fragments. During a transition, the delay values are applied after the respective fragment.

The following shows the resulting sequence:

Early (Source) -> Delay -> Late (Destination) -> Delay

If the transition is bidirectional, the sequence is reversed (more on bidirectional transitions further below):

Delay -> Late (Destination) -> Delay -> Early (Source)

Reverse Transitions

The Transitions framework offers the possibility of reversing transitions. If a reversible fragment has been identified, the already running TransitionFragment shall go backwards, from its current state to the original one.

This feature is optional and can be specified via an optional flag "Is Reversible" in the Properties associated to the selected rule. Default value is true.

A reversible fragment is identified through a Variant that will match a Rule to its corresponding RequestFragment using the following conditions:

Bidirectional Transitions

The "bidirectional" feature allows to define only one transition rule that matches as well the forward as the backwards direction from two request fragments.

The image below shows how two "symmetrical" transition rules can be replaced with only one if the "Is bidirectional" property is enabled:

Bidirectional rules will be applied in the other direction whenever it would be the first match in the ruleset.