[vtk-developers] Update on VTK modularization progress

[Marcus D. Hanwell]

On Wed, Sep 28, 2011 at 7:18 PM, tom fogal <tfogal at sci.utah.edu> wrote:
> We could do that, but it adds more to the link, making shared objects bigger
> and thus causing link and load times to increase.. of course this is a very
> minor concern.

It sounds like the work on modularizing VTK will help a lot here.
>
> Really: we use NetCDF, but we roll it on our own without using any of VTK's
> support.  So the VTK code for this never gets used in our case.
>
> We'd really like to trim out as much as we can from VTK.  We're doing a bit
> better in this regard now I hope, but we still end up supporting a VTK
> version far longer than it should be supported.  And it looks like right now
> we're going to be shipping a VTK very similar to the branch I just pushed,
> which was based off of your 'release' branch at an essentially arbitrary
> point in time.  New issues crop up; for example, newer gcc's (4.5, 4.6) are
> getting more strict on headers and breaking things like the very old
> vtkDICOM code we have in there... and we don't even support loading DICOMs!
>
> The more we can disable the less we have to worry about those kinds of
> issues.
>
It seems like the modularization will benefit you most, and it will
also decouple things like OpenGL from the rendering classes. This is
the much smaller piece of refactoring I mentioned - making
Rendering/Core independent of any OpenGL code. Then Rendering/OpenGL
contains all of the GL/GLSL code, overrides of the object factory etc.

Perhaps you could clone the vtkmodular repository and take a look at
things like Rendering/* and IO/* where many of these things are now
separated out. Some of your patches look good, others are less
relevant for VTK modular.

I would like to finish modularizing what we have before we attempt
major surgery on anything like OpenGL. The advantage of doing this
after is that the GL specific code is isolated to a module.

Marcus