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

[Berk Geveci]

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
>