cogdebugger.ui.fieldvisualizations
EventDrivenViewer
Related Doc:
package fieldvisualizations
Updates the visualization based on the contents of data.
Updates the visualization based on the contents of data.
The src argument was orignally meant to reference the
kernel/field/object that generated the data, in order to support
composite visualizations (that is, viewers that produce a visual based on
the data from several different sources), but launching such viewers in
the current UI is clunky at beset, so this feature isn't used. Viewers
that only visualize a single field's data can probably safely ignore this
arument (and indeed, most of the current ones do).
The field or object that generated the data argument
New field data that needs to be rendered by this viewer
The ComputeGraph's step count at the time the data
argument was generated
A list of properties that should be persisted when the app closes, and restored the next time it's launched.
A list of properties that should be persisted when the app closes, and restored the next time it's launched. A common example of a persistent is the zoom/magnification level of the viewer. Be sure to add any relevenant properties to this list in your Viewer subclasses!
Returns the XML representation of this viewer's properties, suitable for saving into a file.
Returns the XML representation of this viewer's properties, suitable for saving into a file.
Reset the visualization.
Reset the visualization. An optional operation; subclasses must override this method or else it does nothing.
Parses the XML tag produced by the propertiesTag method and restores
any saved valued to this Viewer.
Parses the XML tag produced by the propertiesTag method and restores
any saved valued to this Viewer.
A field viewer that can be subscribed to an event source so as to reacively update its visualizaion in response to new data becoming available.
While you can call the viewer's
updatemethod directly, in the typical usage scenario an EventDrivenViewer will be subscribed to a cogdebugger.Probe that has been registered with the debugger's cogdebugger.ProbeManager. The probe manager will read out the data from any probed fields at regular intervals, raise NewProbeData events, and the viewers will then update themselves. Note however, that the viewer is NOT guaranteed to respond to all NewProbeData events, see more below.The task of visualizing a field can be an expensive operation. Updating and rendering all viewers on a single thread makes for an unresponsive debugger. For this reaon, each EventDrivenViewer contains a Scala Actor that performs the
updateoperation in response to probe date events (callingupdatedirectly on this class does NOT use the actor). Because there is no way of knowing in advance how long an update will take or the rate at which NewProbeData events will be raised, the actor only ever operates on the most recently received probe data, discarding any older messages that may have enqueued in its mailbox. While the actor is busy in theupdatemethod, the volatilebusyvariable will be set to true; a Probe implemenation may take advantage of this to perform additional flow control.---
The intent was to allow for a single viewer to listen to multiple probes, so that it could compose their data in some way. The original motivation for this was Ben+Matthew's Virage tracker, in which they overlayed a moving target on a color image. The target's size, position and color was determined by one field, and the background by another. I don't know exactly what sort of hackery the resorted to go get that to work, but I know it took more effort than it ought to have.
I'd really like this to be an abstract class taking the visualization targets as arguments, but then subclasses can't extend the different Panel classes.