[vtk-developers] VTK modularization update

[David Gobbi]

On Fri, Mar 23, 2012 at 2:59 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Fri, Mar 23, 2012 at 4:02 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> Hi Marcus,
>>
>> I've attached a patched manifest.txt that outlines my ideas for the
>> modularization of Imaging.
>>
>> Imaging/Core
>> Imaging/General
>> Imaging/Sources
>> Imaging/Hybrid
>> Imaging/Stencil
>> Imaging/Morphological
>> Rendering/Image
>>
> Did you try compiling this, or it is just the split you feel is
> appropriate? When it comes to compiling there can be further movement
> necessary, but I can look into this a little.

Right now I'm hoping for a bit of feedback before I take that step.


>> I've considered breaking things down even further, but I'm not sure if
>> there would be a benefit to going this far:
>>
>> Imaging/Color
>> Imaging/Fourier
>> Imaging/Math
>> Imaging/Statistics
>>
>> Actually, though, I really think that more people (developers and
>> customers) need to provide feedback on the way the modules have been
>> split up.  A major reorganization like this requires lots of eyeballs.
>
> We have sent out several calls, and have been circulating this list
> among other developers and customers to get feedback. If there are
> people you are thinking of specifically please let us know.

How much response have you gotten?  I was lazy about looking into this
myself (even though I've been aware of modular for a very long time),
so I imagine that a lot of other developers are the same.

I don't think that my list would be much different from yours: the
core VTK developers (e.g. the Gerrit list), Sandia, Slicer3D, VisIt,
VisTrails, and probably others that I've forgotten about.

 >> One of my major concerns right now is the OpenGL module.  Any app that
>> uses Rendering will have to use OpenGL, but because OpenGL depends on
>> all the other Rendering modules, anyone who uses any part of rendering
>> will have to link to all of Rendering.
>>
>> I propose: the OpenGL classes should go into the various Rendering
>> submodules that use them, e.g. vtkOpenGLCamera belongs with vtkCamera.
>> You've already done this for the OpenGL classes that used to be in
>> Charts: they are included in Rendering/Context2D.
>
> I have the opposite view, I would like to split Rendering/Context2D up
> but it needs some refactoring to make it interface + implementation. I
> think most would stay in Rendering/Context2D and the stuff needing to
> include OpenGL/make GL calls should move to Rendering/Context2DOpenGL
> (or other name that makes sense).
>
> One of our aims was to have the OpenGL implementation in a separate
> module, and what we should probably do is split Rendering/OpenGL up
> further for implementations of the various parts of Rendering.

That would also work.  On a side note, I'd be interested to hear what
the plans are for OpenGL ES.   OpenGL and ES are so similar that it
must be difficult to decide what code to share and what code to split.

 - David


> Thanks for looking into this, we will be pushing several larger
> updates for the wrapping shortly as we have been concentrating on
> getting the three wrapped languages working.