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

Sun Mar 3 09:23:32 EST 2013

This is a really interesting solution that looks to have very little
overhead and seems to be not that invasive.

On Sat, Mar 2, 2013 at 10:21 PM, David Thompson
<david.thompson at kitware.com>wrote:

> Hi all,
>
> > I have been having some conversations about the factories ... 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. ... We could potentially revisit the
> way factories work and optimize it a bit.
>
> Are you thinking of something like this:
>
>
> http://www.altdevblogaday.com/2011/10/27/quasi-compile-time-string-hashing/
>
> ? I think it would be a useful utility in general (for more than just
> object overrides).
>
>         David
> >
> > 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
> >
>
> _______________________________________________
> 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
>
>

-- 
Robert Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130303/058732c6/attachment.html>