AsynchronousUpdates: Difference between revisions
No edit summary |
No edit summary |
||
Line 11: | Line 11: | ||
==Design== | ==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 | 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 s1erver 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. This assumes that the server manager is coded so that commands issued by the client return immediately. | 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. This assumes that the server manager is coded so that commands issued by the client return immediately. | ||
Line 17: | Line 17: | ||
==Implementation== | ==Implementation== | ||
* The set of events enumerated in vtkCommand::EventIds will have to be expanded to include events appropriate to the server manager: | * The set of events enumerated in vtkCommand::EventIds will have to be expanded to include events appropriate to the server manager: | ||
** ServerDisconnected | |||
** UndoStackAdded | |||
** UndoStackDeleted | |||
** ProxyAdded | ** ProxyAdded | ||
** ProxyDeleted | ** ProxyDeleted | ||
** PropertyAdded | |||
** PropertyDeleted | |||
** PropertyLinked | |||
** PropertyUnlinked | |||
** PropertyValueChanged | ** PropertyValueChanged | ||
** PropertyDomainChanged | ** PropertyDomainChanged | ||
** RenderStarted | ** RenderStarted | ||
** RenderProgress | ** RenderProgress | ||
** RenderComplete | ** RenderComplete | ||
* | * Create a new class to manage asynchronous events (simplified for clarity): | ||
* | class vtkSMEvents : | ||
** | public vtkSMObject | ||
* | { | ||
public: | |||
virtual void ProcessEvents() = 0; | |||
}; | |||
* Create a derivative of vtkSMEvents that implements the ProcessEvents() method, and handles pending I/O for all connected servers, emitting asynchronous events as-needed. | |||
* Add a vtkSMApplication::GetEventDispatcher() method that returns a reference to a vtkSMEvents object. | |||
* Clients register with the vtkSMEvents object returned by vtkSMApplication::GetEventDispatcher() to receive events. | |||
* Clients call vtkSMApplication::GetEventDispatcher().ProcessEvents() periodically to give the server manager a chance to handle I/O and emit events. | |||
* (Alternative) If it is determined that a multi-threaded server-manager design is required, clients still register to receive events from the object returned by vtkSMApplication::GetEventDispatcher(), but no longer have to call ProcessEvents(). |
Revision as of 13:41, 5 December 2005
Rough Draft ...
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 responsive at all times.
- Avoid multithreading, see ThreadedGUI.
Use Cases
- Two-or-more clients are connected to a server. Client "A" makes a change to the server state. Client "B", et al, are notified of the change.
- A client with a graphical user interface is connected to a server. The client initiates a time-consuming recalculation of the visualization network. The call to the server should return immediately, and the client should be notified asynchronously as calculation progresses and when the calculations are complete.
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 s1erver 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. This assumes that the server manager is coded so that commands issued by the client return immediately.
Implementation
- The set of events enumerated in vtkCommand::EventIds will have to be expanded to include events appropriate to the server manager:
- ServerDisconnected
- UndoStackAdded
- UndoStackDeleted
- ProxyAdded
- ProxyDeleted
- PropertyAdded
- PropertyDeleted
- PropertyLinked
- PropertyUnlinked
- PropertyValueChanged
- PropertyDomainChanged
- RenderStarted
- RenderProgress
- RenderComplete
- Create a new class to manage asynchronous events (simplified for clarity):
class vtkSMEvents : public vtkSMObject { public: virtual void ProcessEvents() = 0; };
- Create a derivative of vtkSMEvents that implements the ProcessEvents() method, and handles pending I/O for all connected servers, emitting asynchronous events as-needed.
- Add a vtkSMApplication::GetEventDispatcher() method that returns a reference to a vtkSMEvents object.
- Clients register with the vtkSMEvents object returned by vtkSMApplication::GetEventDispatcher() to receive events.
- Clients call vtkSMApplication::GetEventDispatcher().ProcessEvents() periodically to give the server manager a chance to handle I/O and emit events.
- (Alternative) If it is determined that a multi-threaded server-manager design is required, clients still register to receive events from the object returned by vtkSMApplication::GetEventDispatcher(), but no longer have to call ProcessEvents().