[vtk-developers] My vtk class override not being used when an override already exists.

Jean-Christophe Fillion-Robin jchris.fillionr at kitware.com
Sat Mar 2 21:06:16 EST 2013


Hi Berk,

It could be worth investigating the use of the cross-platform c++ library
"CppMicroServices".


"The C++ Micro Services library provides a dynamic service registry based
on the service layer as specified in the OSGi R4.2 specifications. It
enables users to realize a service oriented approach within their software
stack.
The advantages include higher reuse of components, looser coupling, better
organization of responsibilities, cleaner API contracts, etc."
Source: http://cppmicroservices.org/



"Let’s also note that the library is API complete and is now used in
projects like [2] and [3] and companies like [4]. The library also provides
full life-cycle notifications for registered objects, an auto-load
mechanism roughly similar to ITK, powerful service object queries, and puts
an emphasis on the separation of interface and implementation.
[2] http://www.mitk.org
[3] https://github.com/Global-Vision-Systems/Ds4Cpp
[4] http://www.global-vision-systems.com/index.php?Home
"
Source: Link to ITK list.



We started to talk about it with ITK folks. For more information:

  Initial email:
http://article.gmane.org/gmane.comp.lib.itk.devel/932/match=micro+service

and

  Latest answer:
http://article.gmane.org/gmane.comp.lib.itk.devel/939/match=micro+service




Hth
Jc


On Sat, Mar 2, 2013 at 8:47 PM, Berk Geveci <berk.geveci at kitware.com> wrote:

> I have been having some conversations about the factories and what we
> should do with them in the future. One feedback I already received
> (from David Camp, LBNL) was that, due to string comparisons used,
> object factories have a significant impact on performance when
> creating large number of objects. This makes me wonder if broadly
> supporting class overriding with this mechanism is worth the
> performance hit. We could potentially revisit the way factories work
> and optimize it a bit. Or we could say we will enable this feature
> only for select classes - mainly rendering related classes. If you
> want to keep using object factories, maybe you could give us a list of
> classes and we can enable them with factory support. Or maybe the
> improvements that you want to enable via factories can be pushed
> upstream.
>
> On Wed, Feb 13, 2013 at 8:44 PM, Kathleen S. Biagas <biagas2 at llnl.gov>
> wrote:
> > On Wed, 2013-02-13 at 08:50 -0500, Marcus D. Hanwell wrote:
> >> On Tue, Feb 12, 2013 at 8:54 PM, Kathleen S. Biagas <biagas2 at llnl.gov>
> wrote:
> >> > Trying to come up to speed with current VTK master, and ran across
> >> > issues trying to override vtk classes.
> >> >
> >> > One thing I noticed was that I could not override the classes I was
> >> > interested in without first building VTK with
> VTK_ALL_NEW_OBJECT_FACTORY
> >> > enabled.  So my first question is:  are more classes going to be
> opened
> >> > up for overriding within the new scheme of things without having to
> set
> >> > this flag?  Or will this flag be enabled by default in the future?  We
> >> > eventually want our code to compile with a user's preinstalled VTK,
> and
> >> > there wouldn't be a guarantee this flag would have been used.
> >>
> >> I would be interested in knowing which classes you are interested in
> >> overriding that were not. There are several new macros now, and as you
> >> discovered the default one no longer uses the object factory without
> >> the build flag you mentioned. The plan was to leave that off by
> >> default, and add more classes where runtime overrides are needed.
> >
> > One of the classes we override is vtkDataSetMapper, so that we can
> > instantiate specialized mappers for vtkRectilinearGrids and
> > vtkStructuredGrids.  Another is vtkCellDataToPointData, again with
> > specialized handling for vtkStructuredGrids and vtkRectilinearGrids.
> > We also override vtkRectilinearGrid and vtkStructuredGrid to provide
> > implementations with smaller memory footprints.
> >
> > These are all handled correctly if we enable VTK_ALL_NEW_OBJECT_FACTORY.
> >
> >> >
> >> > The other thing I noticed was a change in behavior.  To illustrate, I
> >> > copied the TestObjectFactory.cxx from Common/Core/Testing/cxx, and
> >> > modified it to override vtkCamera instead of vtkPoints.
> >> >
> >> > When built against an older version of VTK, say 5.8, the results show
> >> > that when vtkCamera is instantiated, the correct version (either
> >> > vtkTestCamera or vtkTestCamera2) is succesfully created. Running
> through
> >> > the vtkOverrideInformationCollection printing OverrideWithName, only
> two
> >> > are shown: vtkTestCamera and vtkTestCamera2.
> >> >
> >> > When built against latest version of master, the results show that
> when
> >> > vtkCamera is instantiated, a vtkOpenGLCamera is created instead of
> >> > either of the registered overrides in the test (vtkTestCamera or
> >> > vtkTestCamera2). Running through the vtkOverrideInformationCollection,
> >> > and printing the OverrideWithName, three are shown: vtkOpenGLCamera,
> >> > vtkTestCamera and vtkTestCamera2.
> >> >
> >> That is because the old VTK didn't use the object factory for the
> >> default overrides, and so you could come in and add an additional
> >> override. Now that we use the object factory internally that is
> >> generally the first. As far as I can tell the object factory mechanism
> >> has always returned the first match by default, and will only provide
> >> a list if you use that part of the API.
> >
> > Aah, understand this aspect now, thanks.
> >> >
> >> > In the new scheme of things, how would I go about ensuring my override
> >> > takes precedence over any default ones? eg vtkTestCamera over
> >> > vtkOpenGLCamera?
> >>
> >> The object factory API would need to be modified in some way, this
> >> functionality has never been present. The old hardwired factory
> >> classes for particular kits would first check the object factory, and
> >> if nothing was returned construct the class that was set at compile
> >> time. This meant that effectively you could override the builtin
> >> class, but only once.
> >>
> >> It would be great to know more about what you are doing, and what
> >> classes you are thinking of in VTK that you would like to override.
> >>
> > One of the things we have is a Rendering module, and it overrides things
> > like vtkCamera.  Even enabling the VTK_ALL_NEW_OBJECT_FACTORY flag
> > doesn't allow this to work correctly, due to the OpenGL overrides
> > already existing.
> >
> > I did a little tweaking of the build for this, making it a proper
> > 'Module' in the VTK sense, following instructions I found on
> > http://vtk.org/Wiki/VTK/Module_Development#External_modules
> >
> > I ran into a problem in that vtkExternalModuleMacros.cmake was not
> > included in the VTK install tree.  Is there a specific flag to set
> > during build that allows this to be installed?  In the meantime, I
> > copied this file to the installation, but building this code as a
> > vtkModule still doesn't allow the overrides defined by the module to
> > take precedence.
> >
> > I thought of using vtkObjectFactory::SetAllEnableFlags(0, "vtkCamera")
> > before registering the rendering module's factory, but wasn't sure if
> > that was overkill ...
> >
> > Thanks for the feedback!
> >
> > Kathleen
> >
> >> 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
> >
> _______________________________________________
> 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
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130302/11da91bb/attachment.html>


More information about the vtk-developers mailing list