[vtk-developers] Recent changes

[Volpe, Christopher R (CRD)]

Hi Berk-
 
|> -----Original Message-----
|> From: Berk Geveci [mailto:berk.geveci at kitware.com]
|> 
|> 	There will be some changes:
|> 	1) vtkAttributeDataToFieldDataFilter and 
|> 	vtkDataSetToDataObjectFilter will change,

Ok, this doesn't affect me.

|> 	2) The field data methods for adding/setting arrays 
|> will change. 
|> 	It will not be possible to do 
|> 
|> 	fd->SetField(i, array);
|> 	fd->SetFieldName(i, name);

I don't know of any "SetField" method, but if you meant "SetArray", then this impacts me adversely.
Since the SetNumberOfArrays method doesn't actually allocate the arrays, I have to allocate them and
add them every time I call SetNumberOfArrays. More about this below...

|> 
|> 	This will be replaced by:
|> 	array->SetName(name);
|> 	fd->AddArray(name);

Two issues regarding this:

1) AddArray will take a single "name" parameter? How does this work? Is vtkDataArray going to keep a
list of every instance created so that AddArray can loop over every DataArray in that list and find
the one with the specified name? Sounds very inefficient to me. Even with a hash table, it seems like
overkill for those of us who don't need names associated with their data arrays. Seems to me that the
thing to do would be to have AddArray take a vtkDataArray pointer, as it does now. 

2) I currently use the SetNumberOfArrays method to create room for the initial number of DataArray
pointers that I expect to have. I then instantiate DataArrays and assign them with SetArray(index,
ptr). Since AddArray assumes that the value returned by GetNumberOfArrays reflects the actual number
of non-NULL DataArray pointers, rather than just the amount of space available to hold DataArray
pointers, you have to prohibit use of SetNumberOfArrays. Otherwise, someone might do a
SetNumberOfArrays(5), leaving an array of 5 NULL DataArray pointers, and then do a
AddArray(name_or_pointer) which would then make the number of arrays equal to 6, and assign the
specified DataArray as the 6th element. This implies that the only way to create a FieldData with,
say, 10 vtkDataArrays, is to call AddArray one at a time, which causes the internal array of pointers
to vtkDataArrays to be reallocated and copied each time, resulting in an O(n^2) initialization
routine. 

|> 
|> 	I am moving attribute data (scalars, vector etc...) 
|> into field data. 
|> 	This  is why it will not be possible to set arrays with indices 
|> 	(otherwise, there  is the danger of overwriting attributes
|> unknowingly).

Won't that danger still exist? (E.g. SetTuple(), GetArray()+GetVoidPointer(), etc)

I think there are so many existing ways to shoot yourself int the foot (e.g. ShallowCopy), that
eliminating useful functionality isn't going to buy a whole lot of safety, given the cost of losing
backwards compatibility.

If this absolutely has to be done, then I recommend creating two new methods, SetMaxNumberOfArrays,
and GetMaxNumberOfArrays, that basically do what their non-Max counterparts do now (i.e. allocate the
array of vtkDataArray pointers and return the length of that array, respectively), remove the method
SetNumberOfArrays, and create a new method GetNumberOfArrays which returns the number of times
AddArray has been called, which would have to be kept track of separately from the max number. That
way, I can call SetMaxNumberOfArrays(10), and call AddArray, 5 times for example, very efficiently.
And if I later decide I want the FieldData to have, say, 8 arrays. I can use GetNumberOfArrays to
determine that I need to call AddArray 3 more times.

thanks,
Chris