AsynchronousUpdates

From ParaQ Wiki
Jump to navigationJump to search

Requirements

  • When multiple clients are connected to a server, ensure that server state changes are propagated to all clients so they remain in-sync.
  • Ensure that user interfaces remain as responsive as possible during execution of the visualization pipeline.
  • Provide better feedback to users when executing time-consuming operations.
  • Handle time-consuming operations with multiple server connections.
  • Avoid multithreading, see ThreadedGUI.

Design

VTK already provides a straightforward implementation of Observer Design Pattern, using derivatives of the vtkCommand class, plus methods of vtkObject. The ParaView Server Manager can easily expose an object derived from vtkObject that will allow clients to register observers for server events.

To maintain the responsiveness of graphical user interfaces on the client, the client's event loop must be allowed to run continuously. At the same time, the server manager must also be allowed to run frequently, so that it can handle I/O with connected servers and emit asyncronous events. To accomplish this, the server manager will expose an API function that is called periodically by the client. This function can be called in an idle handler or by a timer, allowing the UI to remain responsive to user input.

Implementation

  • The set of events enumerated in vtkCommand::EventIds will have to be expanded to include events appropriate to the server manager:
Event Description Arguments
ServerConnected emitted when a connection to a server is made, see Secure_Connections pqServer*? Implies that pqServer moves into PVS
ServerDisconnected emitted when a connection to a server ends pqServer*? Implies that pqServer moves into PVS
UndoStackAdded emitted when a client creates a new undo stack vtkSMUndoStack*?
UndoStackDeleted emitted when a client deletes an undo stack vtkSMUndoStack*?
ProxyAdded emitted when a proxy is created vtkSMProxy*
ProxyDeleted emitted when a proxy is deleted vtkSMProxy*
PropertyAdded emitted when a property is added to a proxy vtkSMProperty*
PropertyDeleted emitted when a property is removed from a proxy vtkSMProperty*
PropertyLinked emitted when two properties are linked vtkSMProperty*, vtkSMProperty*
PropertyUnlinked emitted when two properties are unlinked vtkSMProperty*, vtkSMProperty*
PropertyValueChanged emitted when a property value changes vtkSMProperty*
PropertyDomainChanged emitted when a property domain changes (or the domain properties change) vtkSMDomain*
RenderStarted emitted when rendering begins pqServer*?
RenderProgress emitted periodically during rendering to indicate progress pqServer*?
RenderComplete emitted when rendering ends pqServer*?
  • Create a new class to manage asynchronous events (simplified for clarity):
class vtkSMEventDispatcher :
  public vtkObject
{
public:
  void ProcessEvents();
};
  • The implementation of vtkSMEventDispatcher::ProcessEvents() handles pending I/O for all connected servers, emitting asynchronous events as-needed.
  • Add a vtkSMApplication::GetEventDispatcher() method that returns a reference to vtkSMEventDispatcher.
  • Clients register with the vtkSMEventDispatcher object returned by vtkSMApplication::GetEventDispatcher() to receive events.
  • Clients call vtkSMApplication::GetEventDispatcher().ProcessEvents() periodically (from an idle handler or a timer handler) to give the server manager a chance to handle I/O and emit events.
  • Clients without a graphical user interface will have the most difficulty with the requirement to call ProcessEvents() periodically - a Python command-line client might need to call ProcessEvents() in a separate thread, or hack on the Python sources, or use a Qt-based graphical user interface to provide the required behavior.
  • When a client initiates recalculation of the visualization pipeline, the component that collects data from the server (collection filter / Ice-T / etc) will cause the vtkSMEventDispatcher object to emit progress-related events.
  • (Alternative) If it is determined that a multi-threaded server-manager design is required, clients will still register to receive events using vtkSMApplication::GetEventDispatcher(), all that changes is that they no-longer need to call ProcessEvents(), and no-longer block when rendering.