250 likes | 440 Views
ParaView. Current Architecture and History Issues with the Current Design. ParaView Project Goals. Develop an open-source, multi-platform visualization application Support distributed computation models to process large datasets Create an open, flexible and intuitive user interface
E N D
ParaView • Current Architecture and History • Issues with the Current Design
ParaView Project Goals • Develop an open-source, multi-platform visualization application • Support distributed computation models to process large datasets • Create an open, flexible and intuitive user interface • Develop an extensible architecture based on open standards
ParaView Architecture • Parallel VTK as IO, processing and rendering engine • MPI and TCP/IP as network communication • Tcl as scripting language • KW widgets as GUI
ParaView Architecture • XML configurable, extensible GUI • User extensible, open source engine (VTK) • Tool for end-users as well as developers who want to deploy algorithms
Evolution of Architecture • Old architecture MPI On accept: vtkSphereSource sphere0 sphere0 SetPhiResolution 256 On reset: this->Script(“sphere0 GetResolution”); int val = atoi(this->SetValue(this->GetLastResult)); vtkSphereSource sphere0 sphere0 SetPhiResolution 256 vtkSphereSource sphere0 sphere0 SetPhiResolution 256
Evolution of Architecture • Added client/server support
Motivation • Problems with old architecture • Tcl based communication: • String based. Imprecise and inefficient. • Standard Tcl interpreter is not secure. • Dummy pipeline on client: • VTK pipeline objects are not designed to only store state. Some objects misbehave when disconnected or empty. • Communication with server is still necessary to obtain information about distributed data. • Client must be linked to all VTK + VTK Tcl libs
Goals • Binary communication with server where possible • Replace empty pipeline on client with a proxy representation • Separation of pipeline management from GUI to support multiple client types • Provide default implementation of complicated, parallel pipeline and rendering architecture to make client development easy and to reuse code
ParaView Architecture • Data/render server: • C++ • Client/server wrapping • No direct access • Server manager: • C++ API • XML configuration • Tcl, Python or Java scripting (optional)
ParaView Architecture • Desktop Client: • KWWidgets (Tcl/Tk and C++) • Tcl scripting of GUI • XML configuration of GUI • Web Client: • DHTML/JavaScript • Server code uses Python
ServerManager Design • Proxies – VTK objects • Example: Sphere • Properties – Attributes of VTK objects • Example: Radius • Domains – Restrictions on values • Example: Numbers greater than 0
SM: Proxies • Based on proxy design pattern • Proxies are responsible of • Creating server-side VTK objects • Maintaining references to server-side VTK objects using ids • Maintaining a copy of the state of the server-side objects using properties
SM: Properties • Maintain the state of the attributes of the server-side objects • Each property has a set of values and one or more commands to set or get them • Regular and information properties
GUI Design – Main Classes • vtkPVApplication • vtkPVWindow (main window) • vtkPVRenderView (render window, interaction) • vtkPVSource (source/filter proxy) • vtkPVDisplayGUI (display proxy) • vtkPVWidget (property)
GUI Architecture • vtkPVSource and sub-classes implement: • Accept() : push GUI values to server manager then push server manager values to server • Reset() : update the GUI from the server manager • vtkPVWidget and sub-classes follow the same pattern with SM properties.
GUI Architecture • PVSources and PVWidgets are created on the fly based on GUI XML description • GUI events are stored in trace files. • GUI state is stored in state files.
GUI Design Issues • Incomplete implementation of MVC pattern: • GUI (view) can be only partially updated from SM (model) • PVSource can be updated using Reset() • Other pages cannot be updated from SM • GUI pages corresponding to proxy should exist to be updated
GUI Design Issues • Inconsistent access of SM proxies: • PVSource and PVWidgets use Accept()/Reset() • PVDisplayGUI and other pages push values immediately
GUI Design Issues • Rigid GUI design • Access to different types of proxies is different and hard-coded • Proxy/property interface is simple • GUI elements to access any type of proxy should be uniform, simple and XML configurable
GUI Design Issues • Code duplication • Many sub-classes of vtkPVWidget that duplicate functionality of KWWidgets • Trace, state and batch follow separate paths although they perform very similar functions