[vtk-developers] python wrappers & external types

Thu Jul 1 21:41:21 EDT 2010

Ken Martin wrote the original VTK wrapper stuff in like one weekend
(in 1994); if SWIG was around I'm sure it was very immature and we
were young and ambitious :-) Obviously it's been refined a lot since
then, but the original idea was to do something quick and dirty, and
simple. And I am glad that we did not use SWIG because SWIG has severe
scalability problems. We have talked to SWIG's David Beasley about
this, and their model for wrapping is to process a custom,
hand-tailored interface whose interface code is then gathered up into
a single file for compilation. When systems get as big as VTK, this no
longer works due to excessive compile time, and some compilers won't
handle the potentially 100,000's of LOC in the single interface
module. (There are ways to work around this but it gets tricky.)

The timing of this discussion is interesting because in the parallel
universe of ITK, they are looking at the wrapping process which is
hugely more complex due to ITKs extensive templating. As a matter of
fact, due to the generosity of the National Library of Medicine who
are channeling $5 million into ITK starting now, we are going to be
revamping the wrapping process in that system. There are two major
parts to this: the first is to create a "typeless layer" which is
analogous to VTK's under-the-hood switch statement across the basic
data array types. The second part is the choice of wrapping
machinery....believe it or not we have discussed using SWIG (modified
for scalability) and even the VTK wrappers, especially considering the
recent changes that have been made (we are also looking at other
options like Kitware's Mummy product). This is interesting because the
ITK wrapping, although way more sophisticated than VTK's, is generally
considered a big disappointment and most people will not use it
(executables are too large, the process is too cumbersome, the
templated-code is translated into gosh-darn-awful class names and is
type specific, etc.)

So sometimes clean and simple is good :-) And if the ITK guys actually
do create a true typeless layer, we may find that we have the option
to apply the VTK wrapping machinery to it....  (BTW the work has to be
done in approximately one year so it will happen relatively fast).

On Thu, Jul 1, 2010 at 7:18 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> On Thu, Jul 1, 2010 at 5:02 PM, Clinton Stimpson <clinton at elemtech.com> wrote:
>>
>> I've been curious why VTK has its own wrapper generators instead of using
>> something like SWIG.
>
> I don't know who made the original decision, and maybe SWIG wasn't
> even around back then.  Anyway, I'm glad they didn't choose it.  The
> VTK wrappers are very efficient in terms of build-time and very
> lightweight in terms of memory.  Also, unlike SWIG, there is no "pure
> python" layer on top of each C++ class.  Each VTK/Python class is pure
> C++ with a C-Python object interface.
>
>> On Thursday, July 01, 2010 04:45:46 pm David Gobbi wrote:
>>> I've written a few demos and one large application with VTK/Python and
>>> PyQt, so items like this are definitely on my mind as I'm working on
>>> the VTK wrappers.
>>
>> Did you make a general solution to VTK & Qt interoperability in python?
>> Or did you create C++ classes that were wrappable to deal with the VTK + Qt in
>> places where you needed it?
>> Or some other way...?
>
> I wrote the QVTKRenderWidget.py in vtk/qt to allow me to put a
> vtkRenderWindow inside a QWidget.  I haven't used it in a while, but
> I'm guessing that it still works.  No special wrapping was needed,
> just VTK/Python and PyQt.
>
> The trick, though, was that I never used any C++ classes that mixed Qt
> and VTK in their interfaces. I'm guessing that you do.
>
>   David
>
>
>>>
>>> What I'm thinking of doing, now that the wrappers can deal with
>>> "non-vtkObject" objects, is to eventually treat all externals as
>>> opaque types.  So let me know if the following would work for you.
>>>
>>> Tomorrow I'm adding my vtkWrapHierarchy support to VTK, which allows
>>> the VTK wrappers to do the following:
>>> 1) find out if any type they encounter is external to the kit
>>> 2) find the base class of any type in the kit
>>> 3) find the header file for any class in the kit (i.e. for helper classes)
>>>
>>> For my first commit, this information will only be used in a very
>>> crude manner, i.e. to make sure the wrappers don't wrap methods with a
>>> "vtkSomething *" parameter unless "vtkSomething" is derived from
>>> vtkObjectBase.  This will allow the VTK BTX/ETX markers to be
>>> eliminated for such methods.
>>>
>>> In the future, though, external objects could be detected and wrapped
>>> as opaque objects.  They would dealt with using reference semantics
>>> (rather than value semantics) but I don't think that will be a
>>> problem.  As far as the wrappers are concerned, there will just be a
>>> pointer to some unknown object being passed back and forth.  The only
>>> thing that we have to worry about is getting a reference to a
>>> temporary that disappears before the reference does, so it might be
>>> necessary to do some fancy stuff with python weakrefs.  I haven't
>>> thought that far ahead, though.
>>>
>>> If I ever get around to doing it myself, it would be a while before I
>>> could start on it.  But if you are inclined, I can point you to the
>>> interesting places in the code.
>>
>> I'd like you to point me to the interesting places in the code.
>>
>> Clint
>>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>

-- 
William J. Schroeder, PhD
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902