[vtk-developers] Delayed mouse interaction due to event-loop bug in Qt5

Elvis Stansvik 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
> paintEvent().
>
> Clint
>
>
> 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?

Elvis

>
>  - 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
>>> workaround,
>>> 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:
>
>     http://public.kitware.com/pipermail/vtkusers/2016-July/095802.html
>
> Elvis
>
>>
>> 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).
>>
>> Elvis
>>
>>>
>>> Pat
>>>
>>> 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 mailing list