[vtkusers] c# port of VTK

John Biddiscombe jbiddiscombe at skippingmouse.co.uk
Wed Aug 4 11:18:43 EDT 2004


Lars

I think I misunderstood what the original poster is attempting, what are
your views on the following...

1) A managed C++ wrapper around vtk, which could be called by C#, VB, other
managed C++ stuff. Reasonable straightforward, only a speed hit when
populating millions of points/vectors/scalars from .Net code.

2) A C# wrapper generated from vtk, as 1) but with lots of effort in the
wrapper implemetation to ensure types are handled as efficiently a possible.
Call vtk directly from C# (pinvoke or whatever etc)

3) Andy's actually rewritten the entire vtkCommon in C# - ie no back end vtk
DLL's. In this case, I think that he's quite mad and clearly deserves a
medal of some kind. I predict some trouble when he gets to vtkRendering etc.

JB






----- Original Message ----- 
From: "Lars Overgaard" <lov at mikrofyn.com>
To: "'John Biddiscombe'" <jbiddiscombe at skippingmouse.co.uk>;
<seanm at nmr.mgh.harvard.edu>; "'Andy Somogyi'" <endre-somogyi at comcast.net>
Cc: <vtkusers at vtk.org>
Sent: Wednesday, August 04, 2004 3:47 PM
Subject: SV: [vtkusers] c# port of VTK


>
> Sorry, it was never my intention to question anybody's credibility. And
> I am not the one to say whether or not wrappers are the best solution
> for vtk-C#.
>
> Rather, my point is that C# is special - a beauty, and a real beast!
> .Net and managed code introduce a HUGE overhead on function calls and
> data referencing - and automatic garbage collection, not to mention. A
> C# port/wrap/what-ever that does not take this into account could end up
> with a computational performance that is a fraction of what was
> expected. In case of frequent C#->vtk interface calls, it could mean not
> just lost microseconds but rather lost hours.
>
> A vtk wrapper is much easier to maintain than a port, no doubt. On the
> other hand, wrapping reduces performance. It's a classical choice
> between maintenance and performance. Usually, the performance cost of a
> wrapper is quite small, and a wrapper is the obvious choice.
>
> In case of C#, the huge .Net overhead makes the choice less obvious.
>
> Best regards,
> - Lars
>
>
> >>> It's relatively easy to create wrappers for vtk and the overhead is
> >>> minimal in calling them. A lost microsecond when processing hundreds
>
> >>> of MB of data is not worth saving.
>
> >> In general, wrappers have advantages, no doubt about that. But C# is
> >> no just yet another programming language - a lot of things go with
> >> .net. I wonder if this comment comes out of real experience with C#
> >> and managed C++/C wrapping? I think that the overhead can actually
> >> become quite substantial. Great care must be taken to obtain an
> >> efficient C#-based VTK.
>
> >    I cannot speak for John, but I never took him to be referring to
> > C#. Rather, he references the considerable experience of himself and
> > others in using VTK via one of its current wrappers (Java, Python, and
>
> > Tcl). His comment is pretty solid and should be applicable.
>
> _______________________________________________
> This is the private VTK discussion list.
> Please keep messages on-topic. Check the FAQ at:
<http://public.kitware.com/cgi-bin/vtkfaq>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers




More information about the vtkusers mailing list