Difference between revisions of "Slideshow"
(Added engine details) |
(Added section about architecture) |
||
| Line 1: | Line 1: | ||
| − | == | + | == Organization of the Module == |
Module slideshow provides the engine for the Impress slideshow mode. The module has been written from scratch for OO.o 2.0, to replace the | Module slideshow provides the engine for the Impress slideshow mode. The module has been written from scratch for OO.o 2.0, to replace the | ||
| Line 37: | Line 37: | ||
** '''manifest.txt''' | ** '''manifest.txt''' | ||
*** coding and design manifest for slideshow module. changes should adhere to this, or modify the manifest and ''all'' occurences in the module, such that consistency is maintained. | *** coding and design manifest for slideshow module. changes should adhere to this, or modify the manifest and ''all'' occurences in the module, such that consistency is maintained. | ||
| + | |||
| + | == Architecture == | ||
| + | |||
| + | This section is a start at describing the architecture of the slide show. It is far from complete and may contain errors. | ||
| + | |||
| + | === Queues === | ||
| + | |||
| + | The controller functionality is divided into many small parts, often in the form of an action (called Event) whose execution is triggered by events like the end of an animation, a mouse click, or a timer event. | ||
| + | |||
| + | Many of the actions are stored in one of three queues. | ||
| + | |||
| + | ==== EventQueue ==== | ||
| + | |||
| + | The EventQueue is used for two purposes: | ||
| + | |||
| + | * Scheduling of actions that are executed at a specified time, that typically lies in the future. The start of animations (activities) is one example. | ||
| + | |||
| + | * Asynchronous execution of actions from within a fixed thread and environment. These actions are typically scheduled to be executed as soon as possible (zero delay). | ||
| + | |||
| + | The processing of all due actions (whose trigger times lie at or before the time at which | ||
| + | processing is started) is started by SlideShowImpl::update() which | ||
| + | typically is triggered from the sd project. | ||
| + | |||
| + | Actions (remember that they are called Event in the source code) that are | ||
| + | inserted into the queue as a result of processing another action are not necessarily | ||
| + | executed in the same run: zero-delay actions are specified with reference to | ||
| + | the time of their creation but the event queue processing uses the start of | ||
| + | the processing as reference time (both have different ideas of "now"). | ||
| + | For actions whose trigger time lies in the future | ||
| + | this is OK. For actions with zero delay, however, this introduces a latency | ||
| + | of something like 20ms to 50ms and a screen repaint. The delay may or may | ||
| + | not be observable to the user, the screen repaint typically is. | ||
| + | |||
| + | Another sort of problem is introduced by the attempt to have some actions | ||
| + | executed in a specific order (advancing to the next effect should take place | ||
| + | after aborting and skipping the current effect). For this there exists a | ||
| + | second queue inside EventQueue. All actions in this second queue are inserted int the regular queue on each call to EventQueue::process(). | ||
| + | |||
| + | ==== ActivitiesQueue ==== | ||
| + | |||
| + | Set of the currently active activities (parts of effects). On every call to | ||
| + | update all currently active activities are executed. Finished activities are | ||
| + | removed from this set afterward. Activities are inserted into this set by | ||
| + | actions in the EventQueue. | ||
| + | |||
| + | ==== UserEventQueue ==== | ||
| + | |||
| + | A collection of event handlers. Each handler maintains a (sorted) set of | ||
| + | actions that are triggered on certain events. Some events, like the mouse | ||
| + | double click, are triggered by the user (hence probably the name | ||
| + | UserEventQueue), some, like the end of an animation, are not. The execution | ||
| + | of the handlers actions is triggered by the EventMultiplexer. | ||
| + | |||
| + | |||
| + | |||
| + | All three queues could have better names: the EventQueue does not store | ||
| + | events, the UserEventQueue is not one but many queues, and the | ||
| + | ActivitiesQueue is not a queue at all. | ||
| + | |||
| + | |||
| + | |||
| + | === Event Multiplexer === | ||
| + | |||
| + | The EventMultiplexer class is a container of sets of handlers of various kinds of events. Some (most?, all?) of the handlers are provided by the UserEventQueue. Each handler is basically a set (or queue? a queue defines an order on its actions, actions are removed after activation; a set is unordered but actions are only removed when explicitly required) of actions. When a handler is triggered then its actions are executed. | ||
[[Category:source directories]] | [[Category:source directories]] | ||
Revision as of 12:43, 27 April 2009
Contents
Organization of the Module
Module slideshow provides the engine for the Impress slideshow mode. The module has been written from scratch for OO.o 2.0, to replace the outdated engine formerly hardwired into module sd. The module provides a single shared library object, that implements the com.sun.star.presentation.SlideShow UNO service.
- slideshow/
- inc/
- only needed for pch stuff in this module. Slideshow does not export any header files
- prj/
- usual build system boilerplate
- qa/
- debug/
- debugging and logfile analysis tools
- tools/
- other helpful stuff (testdocument generation scripts)
- debug/
- source/
- api/
- com/
- the private UNO API header files, as used by slideshow and sd
- and shared_ptr debugging hooks. only used when compiled with 'debug=t'
- com/
- engine/
- activities/
- SMIL animation activities, as described here
- animationnodes/
- SMIL animation tree nodes, as described here
- shapes/
- implementations for the various shapes on an Impress page, plus import functionality
- slide/
- managing functionality for whole Impress slides (z order, global animation control and event processing)
- and common slideshow functionality, like API bindings, global control and events.
- activities/
- inc/
- api/
- test/
- complete test stub, to run a slideshow standalone (quite barebones, though)
- util/
- usual build system boilerplate
- manifest.txt
- coding and design manifest for slideshow module. changes should adhere to this, or modify the manifest and all occurences in the module, such that consistency is maintained.
- inc/
Architecture
This section is a start at describing the architecture of the slide show. It is far from complete and may contain errors.
Queues
The controller functionality is divided into many small parts, often in the form of an action (called Event) whose execution is triggered by events like the end of an animation, a mouse click, or a timer event.
Many of the actions are stored in one of three queues.
EventQueue
The EventQueue is used for two purposes:
- Scheduling of actions that are executed at a specified time, that typically lies in the future. The start of animations (activities) is one example.
- Asynchronous execution of actions from within a fixed thread and environment. These actions are typically scheduled to be executed as soon as possible (zero delay).
The processing of all due actions (whose trigger times lie at or before the time at which processing is started) is started by SlideShowImpl::update() which typically is triggered from the sd project.
Actions (remember that they are called Event in the source code) that are inserted into the queue as a result of processing another action are not necessarily executed in the same run: zero-delay actions are specified with reference to the time of their creation but the event queue processing uses the start of the processing as reference time (both have different ideas of "now"). For actions whose trigger time lies in the future this is OK. For actions with zero delay, however, this introduces a latency of something like 20ms to 50ms and a screen repaint. The delay may or may not be observable to the user, the screen repaint typically is.
Another sort of problem is introduced by the attempt to have some actions executed in a specific order (advancing to the next effect should take place after aborting and skipping the current effect). For this there exists a second queue inside EventQueue. All actions in this second queue are inserted int the regular queue on each call to EventQueue::process().
ActivitiesQueue
Set of the currently active activities (parts of effects). On every call to update all currently active activities are executed. Finished activities are removed from this set afterward. Activities are inserted into this set by actions in the EventQueue.
UserEventQueue
A collection of event handlers. Each handler maintains a (sorted) set of actions that are triggered on certain events. Some events, like the mouse double click, are triggered by the user (hence probably the name UserEventQueue), some, like the end of an animation, are not. The execution of the handlers actions is triggered by the EventMultiplexer.
All three queues could have better names: the EventQueue does not store events, the UserEventQueue is not one but many queues, and the ActivitiesQueue is not a queue at all.
Event Multiplexer
The EventMultiplexer class is a container of sets of handlers of various kinds of events. Some (most?, all?) of the handlers are provided by the UserEventQueue. Each handler is basically a set (or queue? a queue defines an order on its actions, actions are removed after activation; a set is unordered but actions are only removed when explicitly required) of actions. When a handler is triggered then its actions are executed.
