[vtk-developers] VTK modularization update

[Marcus D. Hanwell]

On Fri, Mar 23, 2012 at 5:38 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> 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 have committed moves that implement your suggested moves. Some were
not possible without refactoring code, I think the changes certainly
seem reasonable as they stand. You could of course consider further
moves after we have merged too.
>
>>> 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 think that we have sent out what is reasonable, and have had some
feedback. There is a certain need to move forward, and we can of
course make changes after we merge in the changes. I would also hope
that those with interest in VTK development monitor the development
list too!
>
>  >> 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.

There is nothing to prevent a module that is depended upon by two
implementation modules with common code. We have been thinking about
how to ensure this is possible, and I think we have done a good job
there. Having modules with all OpenGL code separate allows us to link
to alternative implementations.

There is only so much we can do within the context of modularization
but I have refactored some clases to allow this. I would like to do a
little more of this once we have merged, at the same time gaining
feedback from the wider community. We think we are converging on a
tree that can be merged in the near future.

I have pushed updates to the modular directory (with the manifest) and
the modularized tree (with the new build system in plance). Brad has
been going through the steps of constructing the commits for
modularization (in a similar vein to the commits used for ITK's
modularization).

Marcus