X3D Event Model
Events in X3D are the means for generating and handling behaviors. All changes in the state (including geometry, appearance, animation; but not animated images) are because at least one event was generated and processed. Events can be generated by timers, user interactions, response to other events, or from external sources. Events are routed fro a particular field of a node to another field of a different node. This cycle repeats throughout the time the scene is running.
In X3D V3 events are collected into cascades. The cascade starts with one or more events that do not have a predecessor. Each event may cause one or more events to be generated. THe cascade continues until no more events are available. If an event duplicates a previous event, then X3D's internal event-loop breaker kicks in and the duplciate event is cancelled. The entire event cascade is processed with a singe time-stamp. Once the cascade completes, the new state of the scene is rendered. If the cascade is quite complex or an event requires complex calculations, then rendering (frame) rate of the scene may slow down and produce jerky results. Any new events (e.g., user interaction) produced while the cascade is being processed, but not created by an event in the cascade is held until after this frame is rendered. The X3D event model is described in the V3.3 Standard.
This style of handling all events in a cascade before rendering the frame is not compatible with the operation of the DOM in an HTL5 environment. It fails in two ways
- Events go directly to nodes without following the capture, target, and bubbling phases (see Figure 1 from W3C's DOM Level 3 Events, linked above)
It is important to maintain compatibility with content created under previous versions of X3D. The proposed solution does not change the working of previous versions of X3D. It adds an new execution environment called DOM that is used when X3D is run in a DOM (HTML5) environment. It has the following characteristics:
- Events are processed in the order in which they are generated.
- Events are not timestampped
- There is no requirement for loop breaking of events
- ROUTE statements continue to work as in V3