<div dir="ltr"><div><div><div><div><div>I'm in the unfortunate situation of having to support Qt 5.5.1, and I'm hit by<br>
<br>
    <a href="https://bugreports.qt.io/browse/QTBUG-40889" rel="noreferrer" target="_blank">https://bugreports.qt.io/browse/QTBUG-40889</a><br>
<br>
which was fixed in 5.6 with<br>
<br>
    <a href="https://codereview.qt-project.org/#/c/126136/" rel="noreferrer" target="_blank">https://codereview.qt-project.org/#/c/126136/</a><br>
<br>I've been trying to find a way to work around this bug using a combination of native and non-native event filters in Qt, but haven't really found a good solution.<br><br></div>The problem is I want to use the built-in interactor styles in VTK, such as vtkInteractorStyleTrackballCamera, and these makes calls to Render() as fast as the mouse events arrive.<br><br></div>I have to ask: Is this really a good idea, shoudn't the rendering be governed by a timer during the interaction (say dolly), to be more robust against a flood of mouse events? The reason Qt has even buffered events (and hence opened up for compression, barring that bug) is that the main thread is overworked. And this is due to VTK rendering at every mouse move event.<br><br></div><div>If I make my own completely custom interactor style, I of course have full control and can let a timer govern the rendering, but I was hoping to leverage the built-in ones. And it's not possible to subclass them and disable just the Render calls unfortunately.<br></div><div><br></div>At the moment I don't quite know what to do. Moving the camera around in a VTK window is like syrup, and our product is to run using the Qt 5.5.1 that is packaged in *buntu Xenial :(<br><br></div>Thanks for any advice, especially if you've worked around this problem yourself somehow.<br><br></div>Elvis<br><br></div>