Event Processing order when Vtk Application is slow


There seems to be some issue with the event processing order using VTK version 8.1.0 and Qt version 5.10.

This occurs when there are more graphics rendered in QVTKOpenGLWidget based window, which makes the application slow. [sorry for not sharing a reproducable scenario, couldnt create a small example]

I have created 2 callbacks, one for keypress event and other for mouse events in the same order as mentioned. when we use mouse left click event continuously for say 4 to 5 times, then use key press event. key press event which is used at the end is been processed before some of the left click events.
The left click events are getting slow, guess due to the operation behind it and lot of graphics rendered. These remaining left click events are been processed after the key press event.

Both the callbacks having no priority, rather say same priority.

can someone please inform me if this supposed to happen, can you point me to the VTK classes on how and where the events are getting stacked and processed?

Thanks & Regards,

Qt can compress mouse, pen, and touch events (as devices can generate hundreds of these per second), which might cause some change in the order compared to keyboard events. This is all normal and helps to make your application responsive by avoiding flooding your application with events.

I don’t think you should try to change Qt event handling but instead reduce your rendering time:

  • Upgrade your hardware. A good GPU will easily render very complex meshes and large volumes at well over the maximum refresh rate of your screen.
  • Simplify your models: Simplifying your meshes using quadric decimation or downsampling your volumes by a factor of 10 is often feasible with barely visible change in the rendering result.
  • Use level-of-detail rendering: Speed up rendering while interacting with the view (while the mouse button is down) by reducing the rendering quality. When the mouse button is released, do a full rendering. VTK already fully supports this via level-of-detail actors that can render at different quality level depending on the desired update rate of the render window. You can try how this works in ParaView, which always renders at interactive frame rates, regardless of complexity of the scene.

Thank you @lassoan for your detailed answer.

As QT is handling these events, I have a couple of queries.

  1. Is it true that VTK as a library just process these mouse and keyboard events and doesn’t control the order in which they are invoked? can you point me to code where this interface is written. like the starting point of these events or function when the control for these events is obtained by VTK library to process.

  2. If we wish to eliminate the event handling for these events, like lets say after clicking the escape key I don’t want the stacked events to be processed. In this case if we remove the call backs will it solve our issue. I’m just wondering is there any chance the mouse events and keyboard events can exist in parallel even though we are use only main Thread. Because of the slowness induced and multiple clicks if the above scenario happens I’m thinking that all the operations behind the mouse events and key events should be “Atomic”