[Paraview-developers] RenderModules converted to ServerManager Proxies

[Utkarsh Ayachit]

1) We don't have duplication of logic, since now the displayers and 
DisplayWindow are removed. Batch mode now, can use the same 
rendermodules and display proxies as the GUI does.
2) Since, camera, renderers etc. move becomes subproxies of render 
modules, any GUI element when needing access to serverside objects no 
longer needs to use vtkClientServerStream to get/set values from/to such 
objects. Thus we are getting closer to the goal of the GUI having to 
deal only with ServerManager objects which then deal with the VTK 
objects, and the GUI has no need to directly access the server side VTK 
objects at all.
3) Presently, the batch script is explicity dumped out. Thus, the 
developer has three things to maintain: state, trace and batch!.
Now, batch script is nothing but a description of the server manager 
state. With rendermodules now proxies, we can "soon" use the Server 
Manager state to generate batch and thus no need to explicitly manage 
batch script in GUI.



Moreland, Kenneth wrote:

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