[vtk-developers] Delayed mouse interaction due to event-loop bug in Qt5
elvis.stansvik at orexplore.com
Tue Apr 11 03:19:34 EDT 2017
2017-04-11 1:04 GMT+02:00 <clinton at elemtech.com>:
> That is my preference too.
> It's my understanding this approach is necessary & recommended when using
> QOpenGLWidget. Unless one uses QWidget::repaint to force an immediate
> On Apr 11, 2017 05:07, David Gobbi <david.gobbi at gmail.com> wrote:
> My strong preference is only call Render() within Qt's paintEvent(),
> and to disable Render() everywhere else. Then, when I want VTK
> to render, I call update() on my QWidget to let Qt know that it has
> to re-paint.
> This keeps things nicely synchronized between VTK and Qt, which
> is especially important for things like resizing the window.
> Another thing that I do differently from QVTKWidget is that I install
> a dummy QPaintEngine so that Qt never executes any drawing
> commands within the widget, but that's a separate issue from the
> event loop bug.
Thanks David & Clint for your insights.
David: Is your VTK/Qt widget class something you could share? It
sounds like it has accumulated a lot of battlefield wisdom that could
be useful to others :)
Regarding your noop QPaintEngine, what problem have you bumped into
that this is solving?
> - David
> On Mon, Apr 10, 2017 at 1:13 PM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
> 2017-04-10 21:10 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>> 2017-04-10 20:07 GMT+02:00 Pat Marion <james.patrick.marion at gmail.com>:
>>> Hi Elvis,
>>> In prior emails you mentioned that you use a QVTKWidget subclass (or
>>> QVTKWidget2?) that contains a workaround for this event issue. Is this
>>> class something that you can share? Do you recommend using this
>>> or is the patched qt5.5 preferable?
>> Sure, I'm attaching VTKWidget.h/cpp, which contains the QVTKWidget
>> subclass I'm currently using.
>> If I remember correctly, it was David Gobbi who led me to this
>> workaround, so he should have the credit.
> My bad, it was Clint and David together who helped me out. This was
> the original thread:
>> It's of course preferable to use a fixed Qt (5.6 or higher, or patched
>> 5.5.1), but I'll use this workaround until the patched package is in
>> the xenial-updates repo (the upload to xenial-proposed seems to take
>> some time, I guess the approvers are busy).
>>> On Mon, Mar 20, 2017 at 4:55 PM, Elvis Stansvik
>>> <elvis.stansvik at orexplore.com> wrote:
>>>> > On Mon, Jul 13, 2015 at 16:51:34 -0400, Ben Boeckel wrote:
>>>> >> On Mon, Jul 13, 2015 at 15:00:56 -0400, Ben Boeckel wrote:
>>>> >>> https://codereview.qt-project.org/#/c/115531/
>>>> >> Applying this patch (with one conflicting hunk) to 5.5.0 fixes the
>>>> >> problem for me. I'll poke the review to see if some movement can't be
>>>> >> made.
>>>> > It looks like the patch has been merged for 5.6.0 (due at the end of
>>>> > October).
>>>> Just in case anyone is in the same boat like me, hitting this bug on
>>>> Ubuntu 16.04 LTS (which has Qt 5.5.1), just FYI I'm trying to get an
>>>> SRU (Stable Release Update) going with this fix:
More information about the vtk-developers