QVTK widget is showing slowness in performance when built with vtk 9.3.0 and interacted through mouse/touch/gesture

Development
1

VTK 5 version shows a very smooth version of mouse move operations of qvtk widgets containing vtk images including large image slices including in 3D mode.

In comparison vtk 9.3 shows comparatively slow performance of the same operations.

Some performance improvement noticed (partial improvement in one of the mouse move operations) using VTK_SMP_ENABLED_STDTHREAD flag enabled while building vtk when interactions are one time i.e - mouse double click /click.

However when there are continious interactions taking place i.e mouseMove , still we see performance lag present with little improvement.

As troubleshooting we have tried to figure out in terms of rendering timestamps of the vtk frames during the Move operation and got data showing the performance improvement is still halfway through.

For performance improvement of moving vtk widget built with vtk 9.3 ,is there any other angles to look into ?

Also below observations are noticed.

  1. During mouse move operations throughout , in case of old vtk - 5 .10 - gpu utilization was relatively close to cpu utilization (50 % - 35% , 70% - 50% .. ) where as in case of vtk 9.3 - gpu utilization is much more in comparison to cpu (50 % -5% , 70% - 10%)

  2. In both cases we are going to lower LOD during mouse move operations.

  3. In terms of vtk render windows used - vtkGenericOpenGLRenderWindow* - current vtk version , vtkQtOpenGLRenderWindow2 - in legacy vtk version.

    And vtk renderer and interactors are abstracted inside this.

    Just wondering if we can change this vtk render windows to old versions or tweak with renderers / interactors from the current vtk render window for better results.

2

Hi @ataban, there could be regressions in the Qt widget since there have been interaction-related changes that went in after 9.3. However, since you mentioned that using SMP tools improves performance, I’m wondering if the issue is actually in the pipeline/mapper being used. In other words, the performance differences could be due to a slow filter in your pipeline.

Have you observed similar differences with a simpler or alternative pipeline?

3

@sankhesh , i have done further analysis on the vtk 9 pipeline. Found out that using SetDesiredUpdateRate to 60 gives significant speed closer to vtk 5 in 3D volume rotation of a vtk image with high slice number (2000) compared to setDesiredUpdateRate calculated based on program logic. But at the downside the LOD becomes downraded compared to vtk 5 with same image rotation in 3D. So trying to find out a middle ground where LOD is mimimal downgraded as well as speed is maintained.

Also using APIs like renderer3d->UseDepthPeelingOff();
renderer3d->SetUseFXAA(false);
renderer3d->SetUseSSAO(false);

for speed optimization

Any idea on the problem that without degrading LOD how to improve speed of rotation with/without setDesiredUpdateRate(60)?

4

I recommend using a performance profiler to identify methods or calls that take up significant time, and then determining what optimizations to implement.