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

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.

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?