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

Mon Mar 4 09:02:41 EST 2013

This looks good. Do you have a few spare cycles to investigate what it
would take to do this in VTK? The broader question still remains
though. Should this be enabled for every single class in VTK? My gut
feeling says that we would exclude Common at the least. For one, I am
not very comfortable with people overriding vtkDataArray for example.
Also, it is still a potential performance problem even when doing
something faster like hashing. What do you guys think?

-berk

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