Startup performance

[Meakk]

trafficstars

Describe the bug A large amount of time is spent in the volume mapper initialization when launching f3d even if it's not used

To Reproduce Steps to reproduce the behavior:

1. Open the file using valgrind --tool=callgrind f3d --dry-run cow.vtp --output=/tmp/out.png

Expected behavior The time spent in volume mapper initialization should be negligible

System Information:

• OS: all?
• GPU and GPU driver: irrelevant

F3D Information Paste the content of f3d --version: 2.4 and current master

[kidharb]

I would like to try fixing this bug

[Meakk]

@kidharb here's an idea. We are using vtkNew which allocates the class immediately. Maybe we could use vtkSmartPointer instead and trigger the allocation only when it is needed.

[kidharb]

@kidharb here's an idea. We are using vtkNew which allocates the class immediately. Maybe we could use vtkSmartPointer instead and trigger the allocation only when it is needed.

I finally understand what you mean :-P I was able to reproduce the issue and see that vtkSmartVolumeMapper is taking up some time.

[kidharb]

From @mwestphal comments on Discord (slightly edited for Github)

The problem is that the Volume code is in vtkF3DGenericImporter and all of this Volume code should be in vtkF3DRendererWithColoring::ConfigureVolumeForColoring instead.

In short, vtkF3DGenericImporter should still hold a vtkSmartVolumeMapper which should be nullptr when we start the app. The first time vtkF3DRendererWithColoring::ConfigureVolumeForColoring tries to use vtkSmartVolumeMapper the vtkF3DGenericImporter should initialize it.

To solve this issue, create a vtkF3DGenericImporter::InitializeVolumeMapper and call it just before calling vtkF3DRendererWithColoring::ConfigureVolumeForColoring in vtkF3DRendererWithColoring, if and only if the propAndMapper.second == nullptr

[mwestphal]

@kidharb what is that status of this ?

[mwestphal]

Open to contribution