[vtk-developers] Added support for std::vector to the wrappers

[David Gobbi]

Hi Todd,

VTK already supports the Python buffer interface for moving large amounts
of data between VTK and Python, people have been using it to shuffle arrays
between VTK and numpy for many years.  It's much more efficient than any
iterator-based scheme.

The main goal of wrapping std::vector is convenience: people have already
been using std::vector for things like string lists, so there was a present
demand for this feature.  The reason that I stuck with std::vector rather
than going for a generic iterator-based interface is that it made it easy
for me to piggy-back on the wrappers' existing support for C arrays.  Very
little extra weight was added to the wrappers.

 - David


On Wed, Sep 5, 2018 at 7:20 PM Andras Lasso <lasso at queensu.ca> wrote:

> I find this feature very useful! In application code, we commonly need to
> deal with variable-length arrays. We have been using std::vector accessors
> in C++ and adding vtkStringArray based or GetNumberOf…/GetNth… methods or
> for Python, which has made the API complex and has been very inconvenient
> to use in Python.
>
>
>
> These arrays typically contain up to a few ten elements, therefore, for
> us, convenience is much more important than efficiency.
>
> Most often we return strings and vtkObject* in std::vector, so it would be
> great if vtkObject pointers would be supported, too.
>
>
>
> Andras
>
>
>
>
>
> *From:* vtk-developers <vtk-developers-bounces at public.kitware.com> *On
> Behalf Of *Todd via vtk-developers
> *Sent:* Wednesday, September 5, 2018 8:16 PM
> *To:* David Gobbi <david.gobbi at gmail.com>
> *Cc:* VTK Developers <vtk-developers at vtk.org>
> *Subject:* Re: [vtk-developers] Added support for std::vector to the
> wrappers
>
>
>
> Hi David
>
>
>
> Since std::vector types are unlikely to be small, like coordinate and
> bound arrays, that sounds horribly inefficient; especially when large
> quantities of strings and objects are being marshalled.
>
>
>
> Why not just map the std::vector/std::array to a Python iterator object?
>
>
>
> Todd
>
>
>
> On 6 Sep 2018 4:20 a.m., David Gobbi <david.gobbi at gmail.com> wrote:
>
> Hi Folks,
>
>
>
> Yesterday I merged a patch that allows std::vector<T> to be used from the
> Python wrappers, where T can be 'std::string' or any numeric type from
> 'signed char' to 'float' (including typedefs to those types).
>
>
>
> This means that if you add a C++ method to VTK that takes
> std::vector<std::string>, then in Python you can pass a list or any other
> Python sequence and the wrappers will convert it to a vector for you.
>
>
>
> Method examples that can accept any Python sequence:
>
>     void SetStrings(std::vector<std::string> strings);
>
>     void SetStrings(const std::vector<std::string>& strings);
>
>
>
> Method example that takes a Python mutable sequence (the C++ method can
> write back to the container, since this is pass-by-reference):
>
>     void GetStrings(std::vector<std::string>& strings);
>
>
>
> Method examples that return a vector (which is converted to a Python
> tuple):
>
>     const std::vector<std::string>& GetStrings();
>
>     std::vector<std::string>& GetStrings();
>
>     std::vector<std::string> GetStrings();
>
>
>
> Note that std::vector is not 'wrapped' per se.  Instead, what is going on
> here is that the wrappers are converting to/from Python container types. My
> primary goal was convenience rather than efficiency, we can always add a
> wrapped std::vector type at a later date without sacrificing the
> convenience of automatic conversion.
>
>
>
> Chances are good that I'll be able to add std::vectors of VTK objects
> (smart or dumb pointers) and vtkVariant before VTK 9, but only if someone
> adds methods to VTK that take parameters of those types (as far as I know,
> there aren't any yet).
>
>
>
> See the following VTK gitlab issue for additional information:
>
> https://gitlab.kitware.com/vtk/vtk/issues/17362
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fvtk%2Fvtk%2Fissues%2F17362&data=02%7C01%7Classo%40queensu.ca%7C0e1f3f218b5543a5524608d6138e03b5%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636717898021517951&sdata=9vohuaiduQLCm6pfGlMxQbXL4hYutf1fKB6SafvQE4c%3D&reserved=0>
>
>
>
> The following is a list of VTK methods that take std::vector that have
> been wrapped due to this change (it is a short list, since people have
> historically avoided using std::vector as part of the VTK public API due to
> the obvious reason that they didn't want to exclude their methods from
> wrapping):
>
>
>
> vtkActor::ProcessSelectorPixelBuffers
>
> vtkAMRInformation::GetNumBlocks
>
> vtkCompositePolyDataMapper2::ProcessSelectorPixelBuffers
>
> vtkMapper::ProcessSelectorPixelBuffers
>
> vtkMultiProcessStream::GetRawData
>
> vtkMultiProcessStream::SetRawData
>
> vtkOpenGLGlyph3DHelper::GlyphRender
>
> vtkOpenGLIndexBufferObject::AppendTriangleIndexBuffer
>
> vtkOpenGLIndexBufferObject::AppendLineIndexBuffer
>
> vtkOpenGLIndexBufferObject::AppendTriangleLineIndexBuffer
>
> vtkOpenGLIndexBufferObject::AppendPointIndexBuffer
>
> vtkOpenGLIndexBufferObject::AppendStripIndexBuffer
>
> vtkOpenGLIndexBufferObject::AppendEdgeFlagIndexBuffer
>
> vtkOpenGLMoleculeMapper::ProcessSelectorPixelBuffers
>
> vtkOpenGLPointGaussianMapper::ProcessSelectorPixelBuffers
>
> vtkOpenGLPolyDataMapper::HandleAppleBug
>
> vtkOpenGLPolyDataMapper::ProcessSelectorPixelBuffers
>
> vtkOpenGLVertexBufferObject::SetShift
>
> vtkOpenGLVertexBufferObject::SetScale
>
> vtkOpenGLVertexBufferObject::GetShift
>
> vtkOpenGLVertexBufferObject::GetScale
>
> vtkOpenGLVertexBufferObject::GetPackedVBO
>
> vtkParallelAMRUtilities::DistributeProcessInformation
>
> vtkProp::ProcessSelectorPixelBuffers
>
> vtkResourceFileLocator::Locate
>
> vtkShadowMapPass::ShadowMapTransforms
>
> vtkShadowMapPass::GetShadowMapTextureUnits
>
> vtkSparseArray::GetUniqueCoordinates
>
> vtkUnicodeString::utf16_str
>
>
>
> Cheers,
>
>  - David
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20180905/2f7d0426/attachment-0001.html>