[vtk-developers] ExecuteData method

Ken Martin ken.martin at kitware.com
Fri Apr 13 09:21:28 EDT 2001

Hello Folk,

I have made some recent changes to VTK’s UpdateData method. Basically there
were a few problems I was trying to address:

1.                 for filters with more than one output, only the output
that is currently updating has a valid UpdateExtent. To allocate data in the
Execute method you need to know which output is currently updating so you
can look at its UpdateExtent.
2.                 People writing filters were getting confused about what
Execute method to use. There was Execute() Execute(vtkImageData *)
Execute(vtkImageData *, vtkImageData *) Execute(vtkImageData **,
vtkImageData) Execute(vtkImageData **,vtkImageData **) all defined and most
of them were defined in the superclass, causing subclasses to override all
of them from their superclasses. This proved a little ugly and confusing for
new filter writers.
3.                 Try to make imaging and graphics more consistent

So I modified UpdateData(vtkDataObject *) to call a new method
ExecuteData(vtkDataObject *) instead of Execute().  For backwards
compatibility I added a default implementation of ExecuteData that just
calls Execute(). So for graphics filters you can still use Execute.  For
imaging filters I changed some superclasses so that if you are using
ThreadedExecute you are OK. Otherwise you will need to switch over to
ExecuteData. My current plan is to change all the other filters in VTK to
use ExecuteData (just a perl script) but leave in the default implementation
of ExecuteData that calls Execute for now. The only reason I haven’t done
this already is that I’m still not 100% sure I like that signature.
Occasionally I think the signature should be

ExecuteData (int numInputs, vtkDataObject **inputs, int numOutputs,
vtkDataObject **outputs, int currentOutput)

That would allow in the future the pipeline control to be completely removed
from the filters. Basically a filter could be though of as a functional
element then. The pipeline control could be encapsulated into a separate
object then. For now I’m not going to change anything else but I was curious
if anyone had any thoughts on the issue.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtk-developers/attachments/20010413/2cf4a720/attachment.htm>

More information about the vtk-developers mailing list