[Paraview-developers] Re: Pipeline 'split'

[Berk Geveci]

Hi.

I don't exactly understand what "pipeline split" is. I will describe
shortly what I have been doing:

Objective: Separate ParaView's server management code from the GUI code.

Current state: ParaView uses a loose proxy pattern to drive the server.
Each object on the server is represented by an id and is accessed by the
client through this id and the stream based wrappers.

Problems: 

* The server access is spread throughout the ParaView code and the
method used to manage objects vary depending on the class (and the
programmer who implemented the class). For example, a filter is
manipulated directly by a PVSource, PVWidget, PVWidgetProperty.

* There is no uniform method to access VTK objects on the server. For
example, RenderModules access the RenderWindow directly (a RenderModule
has an ivar that is the id of the RenderWindow), whereas PVSources use
PVWidgets and PVWidgetProperties to access the sources (PVSource has a
an ivar that is the ids of the filters it maintains and it passes this
to other objects as necessary).

* It is not possible to re-use any ParaView code to write another
client.

Solution:

Separate the part of ParaView that manages the VTK objects on the server
to an independent module (i.e. a library that ParaView client links to).
This module consists of:

* Proxy classes: Actually, a combination of proxy and adapter patterns.
While providing a way to manipulate one or more VTK objects of the same
class on the server, the proxy does not duplicate the interface of the
object it manages. Rather, it provides an adapter that makes the
interface more uniform.

* Property classes: There are read and write properties. Write
properties usually correspond to SetXXX methods. However, they can do
much more complicated things under covers. Read properties usually
correspond to PVInformation objects. They provide some sort of
information about the VTK object(s) they are associated with. For
example, the (whole) bounds of a (data parallel) data object.

Proxies and properties are described in XML. Currently, the
configuration file is created manually. It would be nice to have it
semi-automatically generated (not in our radar right now).

We did not use the "thin" proxy described by Brian because it provides
very little advantage over directly accessing the VTK objects through a
wrapping layer such as Tcl or Client/Server streams. The proxies and
properties I described above provide a thicker layer that implement:
- composite objects : the client does not have to create a mapper,
actor, renderer, renderwindow. Instead, it creates displayers and
display windows. We create a small pipeline (for example, geometry
filter-mapper-actor) in these classes and set good default values.
Furthermore, we can automatically instantiate the right sub-class
depending on whether ParaView is running on batch, tiled display,
chromium mode etc.
- algorithms to access the VTK objects in parallel to get things like
total number of points, bounds etc.
- functionality that is not in VTK yet. A good example is multi-block
support. 

What I have so far:

1. Nothing is committed to ParaView. All code is my work repository.
2. A hierarchy of proxy and property classes, with an xml parser to
create and configure objects from these
3. A modified ParaView tree that writes out Tcl batch files driving the
server manager. This will be re-done once I start incorporating the
server manager into ParaView proper.

The next release (1.4) will use the server manager only in batch
scripts.

I will provide more information and documentation once we branch 1.4.
Right now, I am very busy trying to get the batch working as much as I
can for 1.4. The current batch does NOT work. I actually wanted to write
a short message but got excited and wrote this loooong one instead. My
apologies :-)

-Berk  
 


> On Mar 24, 2004, at 9:42 AM, Wylie, Brian wrote:
> 
>          
>         ...
>
>
>         I'd like to see the pipelinesplit work be closely related to
>         the 'proxy' pattern. Below in anexample of how this works.
>         Basically the remote object looks like alocal object. This
>         type of mechanism seems to me to be very flexibleand
>         straightforward. All the classes that will be proxy enabled
>         willget auto generated in a form similar to the tcl wrapping.
>         
>         Machine1:
>         
>           vtkConeSource *cone =vtkConeSource::New();
>         
>           vtkPolyDataMapper*coneMapper = vtkPolyDataMapper::New();
>                 coneMapper->SetInput(cone->GetOutput() );
>         
>           vtkActor *coneActor =vtkActor::New();
>                 coneActor->SetMapper(coneMapper );
>         
>           vtkRenderer *ren1=vtkProxyRenderer::New();
>                 ren1->SetHost("machine2" );
>                 ren1->AddActor(coneActor );
>          
>         
>         Machine2:
>         
>         vtkActor *coneActor =vtkProxyActor::New();
>                 coneActor->SetHost("machine1" );
>                 coneActor->SetMapper(coneMapper );
>         
>           vtkRenderer *ren1=vtkRenderer::New();
>                 ren1->AddActor(coneActor );
>         
>           vtkRenderWindow *renWin =vtkRenderWindow::New();
>                 renWin->AddRenderer(ren1 );
>          
>         
>         ...
>
>         BrianWylie
>         Sandia NationalLaboratories
>         MS 0822 - Org 9227 - Building880/A1-J
>         (505) 844-2238   FAX (505)845-0833