[Paraview-developers] RenderModules converted to ServerManager Proxies

[Moreland, Kenneth]

Could you elaborate on the benefits this change will give to the ParaView API (particularly for client apps)?  You mention a common interface, but I do not understand what the proxy interface really buys you over the polymorphism of class inheritance.  The properties supported by the server manager object should follow the class hierarchy.  When would you know about a set of properties for a specific render module but not know enough to down cast the class directly?
 
-Ken
 

________________________________

From: paraview-developers-bounces at paraview.org on behalf of Utkarsh Ayachit
Sent: Fri 4/15/2005 11:25 AM
To: paraview-developers at paraview.org
Subject: [Paraview-developers] RenderModules converted to ServerManager Proxies



Update on changes to the rendermodules I will be committing this afternoon:
We have converted all the rendermodules and part displays to proxies. Thus,
one no longer needs to access them using their peculiar API, instead use the
proxy-property interface, just like any other VTK source/filter proxy.

Following is a rough mapping between the old rendermodule classes and the
new proxies.
vtkPVRenderModule                       --> vtkSMRenderModuleProxy
vtkPVSimpleRenderModule                 --> vtkSMSimpleRenderModuleProxy
vtkPVLODRenderModule                    --> vtkSMLODRenderModuleProxy
vtkPVCompositeRenderModule              --> vtkSMCompositeRenderModuleProxy
vtkPVCaveRenderModule                   --> vtkSMCaveRenderModuleProxy
vtkPVDeskTopRenderModule                -->
vtkSMIceTDesktopRenderModuleProxy
vtkPVIceTRenderModule                   --> vtkSMIceTRenderModuleProxy
vtkPVMultiDisplayRenderModule           -->
vtkSMMultiDisplayRenderModuleProxy

All render modules proxies are servermanager objects and hence cannot be
accessed from the process module (earlier process module would create the
render modules, now it's the application (vtkPVApplication) that creates and
maintains a pointer to the render module.

Similarly, all the part displays have been restructured to define a property
interface (in ServerManager XMLs) so that they too can be accessed using the
property API.

vtkSMPartDisplay                        --> vtkSMSimpleDisplayProxy
vtkSMLODPartDisplay             --> vtkSMLODDisplayProxy
vtkSMCompositePartDisplay       --> vtkSMCompositeDisplayProxy
vtkSMMultiDisplayPartDisplay    --> vtkSMMultiDisplayProxy
vtkSMCubeAxesDisplay            --> vtkSMCubeAxesDisplayProxy
vtkSMPlotDisplay                        --> vtkSMXYPlotDisplayProxy

Earlier, the part display pointer was obtained from the PVSource. Now,
instead, one would obtain the DisplayProxy pointer
(vtkPVSource::GetDisplayProxy()) and instead of directly calling methods on
the display object use properties or use convenience methods defined on the
display proxy (convenience methods do the same thing as  getting a property
with a specific name,and to set the value: they are just defined for
convenience and are named with a ....CM appended eg.
vtkSMDisplayProxy::SetColorCM().)

The render module proxy provides pointer to the client side
renderers/renderwindow/camera. However, typically, one is advised to use
properties to access any of there methods eg. One should use the properties
(such as CameraFocalPoint) exposed by the Render Module proxy to change
camera properties.

Also, the ServerManager XML capabilities have been expanded (see
documentation of vtkSMProxy, vtkSMProperty).

These changes would entail that code using the rendermodules/ part displays
will have to change, but hopefully, this won't be too difficult.

Utkarsh.

_______________________________________________
Paraview-developers mailing list
Paraview-developers at paraview.org
http://public.kitware.com/mailman/listinfo/paraview-developers



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/mailman/private/paraview-developers/attachments/20050416/fc74a5a1/attachment.html