<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-07-02 12:12 GMT+02:00 Elvis Stansvik <span dir="ltr"><<a href="mailto:elvis.stansvik@orexplore.com" target="_blank">elvis.stansvik@orexplore.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks to both of you for your answers.<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2016-07-02 1:13 GMT+02:00 David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Fri, Jul 1, 2016 at 4:08 PM, <span dir="ltr"><<a href="mailto:clinton@elemtech.com" target="_blank">clinton@elemtech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><div><div><br></div><div><br></div><div><span>----- On Jul 1, 2016, at 7:07 AM, Elvis Stansvik <<a href="mailto:elvis.stansvik@orexplore.com" target="_blank">elvis.stansvik@orexplore.com</a>> wrote:<br></span></div></div></div><div><div><div><blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><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><br>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></div></blockquote><div><br></div></div></div><div>I think this problem is related to not following the Qt recommended way of doing rendering with mouse events.</div><div>What Qt 5.5 would like to do is give you 2 or maybe 3 mouse events per render.</div><div><br></div><div>To do that with VTK, you can implement a render callback for the interactor, which calls QVTKWidget::update(), then overload QVTKWidget::paintEvent() to call vtkRenderWindow::Render() instead of vtkRenderWindowInteractor::Render().</div><div><br></div><div>This is what I have done to gain back the responsiveness.</div><div>I've had thoughts in the past about proposing a vtkRenderWindowInteractor::RequestRender() function which the interactor style classes can use, which might help solve this problem. But then with Qt 5.6, the problem goes away.</div></div></div></blockquote></span></div></div></div></blockquote><div><br></div></span><div>This worked great and is a much simpler workaround than I had in mind. Thanks!<br><br></div><div>For reference to others, what I did in the QVTKWidget subclass I was experimenting with was:<br><br>SampleWidget::SampleWidget(QWidget *parent, Qt::WindowFlags f) : QVTKWidget(parent, f)<br>{<br></div><div> // Set up some stuff (cylinder, polymapper, renderer)<br><br> GetInteractor()->AddObserver(vtkCommand::RenderEvent, this, &SampleWidget::onInteractorRender);<br></div></div></div></div></blockquote><div><br></div><div>In fact, I could use update() as the callback directly:<br><br> GetInteractor()->AddObserver(vtkCommand::RenderEvent, this, &SampleWidget::update);<br><br></div><div>Elvis<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> GetInteractor()->SetEnableRender(false);<br>}<br></div><div><br>void SampleWidget::paintEvent(QPaintEvent *event)<br>{<br> Q_UNUSED(event);<br><br> if (updatesEnabled()) {<br> GetRenderWindow()->Render();<br> }<br>}<br><br>void SampleWidget::onInteractorRender(vtkObject* caller, long unsigned int eventId, void* callData)<br>{<br> Q_UNUSED(caller);<br> Q_UNUSED(eventId);<br> Q_UNUSED(callData);<br><br> update();<br>}<br><br></div><div>The GetInteractor()->SetEnableRender(false) was one important part, otherwise the interactor would still issue direct calls to Render on the render window.<br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div><div><br></div></span><div>I don't use the interactors, but apart from that my Qt widget does what Clint describes:</div><div><br></div><div>void cbQtWidget::paintEvent(QPaintEvent *)</div><div>{</div><div> if (updatesEnabled()) {</div><div> m_ViewFrame->Render(); // calls vtkRenderWindow::Render()</div><div> }</div><div>}</div></div><br></div><div class="gmail_extra">This is the only place where I allow a render to occur. Qt is 100% in charge.</div></div></blockquote><div><br></div></span><div>Yep, this worked fine. And with Clint's maneuver I could also make use of the interactor/interactor styles.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">However, since VTK no longer renders for every input event, I have to be careful when I use the VTK picker. I wrote a method called UpdatePropsForPick() that I call for every input event, and it ensures that the picking works correctly regardless of whether the Render()s are actually happening.</div></div></blockquote><div><br></div></span><div>Ah, this is good advice. Would you mind sharing how it ensures this? Not necessarily in code, but just in a few words? I'm quite new to VTK and haven't done any picking yet.<br><br></div><div>Elvis<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra"> - David</div><div class="gmail_extra"><br></div></font></span></div>
</blockquote></div><br></div></div>
</blockquote></div><br></div></div>