1 / 23

ParaView

Explore the evolution of ParaView architecture, issues with the current design, goals, and the motivation behind enhancing the architecture. The text delves into the transition from old to new architecture, client/server support, and the binary communication with servers. It also details ParaView architecture components such as Data/render server, Server Manager Design, and GUI Architecture, emphasizing the need for a more efficient and user-friendly design. Additionally, it addresses issues related to GUI design, including incomplete MVC pattern implementation, inconsistent proxy access, and code duplication.

katherineboyd
Download Presentation

ParaView

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ParaView • Current Architecture and History • Issues with the Current Design

  2. 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

  3. 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

  4. 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

  5. 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

  6. Evolution of Architecture • Added client/server support

  7. 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

  8. 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

  9. ParaView Architecture

  10. ParaView Architecture • Data/render server: • C++ • Client/server wrapping • No direct access • Server manager: • C++ API • XML configuration • Tcl, Python or Java scripting (optional)

  11. 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

  12. ServerManager Design • Proxies – VTK objects • Example: Sphere • Properties – Attributes of VTK objects • Example: Radius • Domains – Restrictions on values • Example: Numbers greater than 0

  13. Server Manager Design

  14. 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

  15. 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

  16. SM: Properties

  17. GUI Design – Main Classes • vtkPVApplication • vtkPVWindow (main window) • vtkPVRenderView (render window, interaction) • vtkPVSource (source/filter proxy) • vtkPVDisplayGUI (display proxy) • vtkPVWidget (property)

  18. 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.

  19. 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.

  20. 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

  21. GUI Design Issues • Inconsistent access of SM proxies: • PVSource and PVWidgets use Accept()/Reset() • PVDisplayGUI and other pages push values immediately

  22. 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

  23. 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

More Related