Filters deleting output

[John Biddiscombe]

Charles,

>I assume that the only time one of these filters will delete their output 
>is when there input is changed (vtkElevationFilter) or the FileName is 
>changed for vtkDataSetReader.  Since the application is changing the input, 
>why can't it deal with the output changing too.

Well - it can. But ....


if you had

unknown data (from DataSetReader)
--->ElevationFilter
--->WarpScalars
--->TextureMapToPlane
etc etc

changing the input file name requires changing the outputs->input links to
all the succeeding filters

loop(......)
	datasetreader->SetFileName(a file name);
	elevationfil->SetInput(datasetreader->GetOutput());
	warper->SetInput(elevationfil->GetOutput());
	texturer->SetInput(warper->GetOutput());
	stuff = texturer->GetOutput();
	do interesting processing
}

will work, as each loop resets each input by fetching the new output.


but this won't work

box 1
elevationfil->SetInput(datasetreader->GetOutput());

box 2
warper->SetInput(elevationfil->GetOutput());

box 3
texturer->SetInput(warper->GetOutput());

loop(......)
	datasetreader->SetFileName(a file name);
	texturer->Update();
}

because clearly the inputs are deleted by the owners during changes.

Now if you argue that this sort of behaviour shouldn't be supported, then
fair enough. But if you try to "modularize" vtk into a set of discrete
processing units (like in a gui environment where each filter is wrapped in
its own window), you want to avoid having to wrap an additional layer on
top of the update chain and track each input set/get.

What I mean is. Yes as you say, it is possible to monitor each input, check
when its changed and discard outputs (for each box as above) - and
propagate this change upwards through the pipeline. However its a
grotesquely inelegant way of doing it.

If each vtkProcessObject simply had a callback which was called whenever an
output was changed (by which I mean - the pointer went out of scope), then
the process can be encapsulated and the propagation of changes up the
pipeline becomes automatic - as opposed to forced. The programmer can respond
to changes as they occur, rather than having to proactively check for
changes.

I guess its a style/opinion/get feeling really. I'm also guessing that this
is something you are aware of at kitware - otherwise you wouldn't issue the
warning when the output was changed!

As a final point...
Just suppose you had a vtkUnusualGeometryFilter
and it had some options
GenerateStructuredOutputOn/Off
Now it might produce Polydata normally, but instead produce a StructuredGrid
if this option was set. Or maybe a Rectilinear/StructuredGrid depending upon
spacing of voxels etc etc.
Now the programer would have to consider not only the input to the filter, but
also the options set, and (in principle) to make his program general purpose 
would need to know each and every filter in depth and take into consideration
their behaviour when checking outputs. The inclusion of a callback makes the 
job of accounting for this so much simpler.

ttfn

John B




-----------------------------------------------------------------------------
This is the private VTK discussion list.  Please keep messages on-topic.
Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at gsao.med.ge.com>.  For help, send message body containing
"info vtkusers" to the same address.     Live long and prosper.
-----------------------------------------------------------------------------