[vtk-developers] VTK modularization update

Marcus D. Hanwell marcus.hanwell at kitware.com
Fri Mar 23 16:59:54 EDT 2012


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.

> 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.
>
> 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.

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.

Marcus
>
> On Mon, Mar 19, 2012 at 8:31 AM, Marcus D. Hanwell
> <marcus.hanwell at kitware.com> wrote:
>> On Sun, Mar 18, 2012 at 8:39 PM, Aashish Chaudhary
>> <aashish.chaudhary at kitware.com> wrote:
>>>> As some of you may know, VES and Kiwi are customers of vtkmodular, via a
>>>> cmake superbuild (ExternalProject_Add.)  The superbuild currently uses
>>>> vtkmodular from last September.  Not sure that I'll have time right away,
>>>> but I hope to check out the recent vtkmodular progress and bring kiwi up to
>>>> date with master.
>>>>
>>>> The VES dashboard may be of some value, since it builds vtkmodular in
>>>> cross compile mode, using Android and iOS toolchains.  It would be really
>>>> great to have builds using vtkmodular from nightly master.
>>>
>>> This sounds like a great idea, also it would be nice to move away from
>>> external gitorious.
>>
>> The aim is to get modular merged into master in the next week or two,
>> and so this would be everywhere VTK is mirrored.
>>
>> Marcus
>> _______________________________________________
>> 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
>>



More information about the vtk-developers mailing list