VtkArray Changes for In-Situ Array Mapping

There are plans to replace the vtkDataArrays with the vtkArray hierarchy. As we make this change, we should also consider the possibility of changing the layout of the memory used in the class. This is mostly important when considering using VTK in-situ with simulation. The solver may well store data in a layout different than that implicitly specified by VTK. We wish the vtkArray hierarchy to encapsulate the layout of the internal memory and make it straightforward to provide a new subclass of vtkArray that will naturally be used properly by filters without deep memory copies.

The Main Problem

The main problem with the vtkArray hierarchy with respect to switching memory array layouts is the existence of the method vtkDenseArray::GetStorage(). This method returns the raw array used in vtkDenseArray, and it is assumed to have a particular layout. The problem is that if one is to subclass vtkDenseArray to support a different layout, this class would have to override this method to allocate a new array and copy the data.

There are legitimate reasons to get the raw array from a vtkDenseArray. However, the interface should discourage this use unless actually necessary. The interface should make clear that an allocation and deep copy might occur. For the filter programmer, it should be easier (and efficient) to operate directly against the interface of the array itself.

To use vtkArray in place of vtkDataArray, the implementation (at least initially) will reimplement the vtkDataArray hierarchy to interally use vtkArray. The vtkDataArrays should also deprecate the GetPointer and GetVoidPointer methods for the same reason. The correct way to get these pointers should be to get the underlying vtkArray and getting the array from there.