Re: Delayed mouse interaction due to event-loop bug in Qt5

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delayed mouse interaction due to event-loop bug in Qt5

Elvis Stansvik
> 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:

  https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173

Elvis
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delayed mouse interaction due to event-loop bug in Qt5

Pat Marion-2
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?

Pat

On Mon, Mar 20, 2017 at 4:55 PM, Elvis Stansvik <[hidden email]> 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:

  https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173

Elvis
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delayed mouse interaction due to event-loop bug in Qt5

Elvis Stansvik
2017-04-10 20:07 GMT+02:00 Pat Marion <[hidden email]>:
> 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.

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
> <[hidden email]> 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:
>>
>>
>> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173
>>
>> Elvis
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers


VTKWidget.h (668 bytes) Download Attachment
VTKWidget.cpp (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delayed mouse interaction due to event-loop bug in Qt5

Elvis Stansvik
2017-04-10 21:10 GMT+02:00 Elvis Stansvik <[hidden email]>:

> 2017-04-10 20:07 GMT+02:00 Pat Marion <[hidden email]>:
>> 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
>> <[hidden email]> 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:
>>>
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173
>>>
>>> Elvis
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delayed mouse interaction due to event-loop bug in Qt5

David Gobbi
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.

 - David


On Mon, Apr 10, 2017 at 1:13 PM, Elvis Stansvik <[hidden email]> wrote:
2017-04-10 21:10 GMT+02:00 Elvis Stansvik <[hidden email]>:
> 2017-04-10 20:07 GMT+02:00 Pat Marion <[hidden email]>:
>> 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
>> <[hidden email]> 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:

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delayed mouse interaction due to event-loop bug in Qt5

Clinton Stimpson
In reply to this post by Elvis Stansvik
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 <[hidden email]> 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.

 - David


On Mon, Apr 10, 2017 at 1:13 PM, Elvis Stansvik <[hidden email]> wrote:
2017-04-10 21:10 GMT+02:00 Elvis Stansvik <[hidden email]>:
> 2017-04-10 20:07 GMT+02:00 Pat Marion <[hidden email]>:
>> 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
>> <[hidden email]> 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:


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delayed mouse interaction due to event-loop bug in Qt5

Elvis Stansvik
2017-04-11 1:04 GMT+02:00  <[hidden email]>:

> 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 <[hidden email]> 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
> <[hidden email]> wrote:
>
> 2017-04-10 21:10 GMT+02:00 Elvis Stansvik <[hidden email]>:
>> 2017-04-10 20:07 GMT+02:00 Pat Marion <[hidden email]>:
>>> 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
>>> <[hidden email]> 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:
>
>
_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delayed mouse interaction due to event-loop bug in Qt5

David Gobbi
On Tue, Apr 11, 2017 at 1:19 AM, Elvis Stansvik <[hidden email]> wrote:

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 :)

It's part of an internal project, so I can't release it (or at least, not yet).

Regarding your noop QPaintEngine, what problem have you bumped into
that this is solving?

This was needed in order to get rendering to work on a Windows system.
Qt was always erasing the VTK scene by painting over it with the widget's
background color.  I tried setting the WA_NoSystemBackground flag and
the WA_PaintOnScreen flag to stop Qt from doing this, but the only trick
that always worked was replacing the QPaintEngine with a dummy. 

 - David

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Delayed mouse interaction due to event-loop bug in Qt5

Elvis Stansvik

Den 11 apr. 2017 6:04 em skrev "David Gobbi" <[hidden email]>:
>
> On Tue, Apr 11, 2017 at 1:19 AM, Elvis Stansvik <[hidden email]> wrote:
>>
>>
>> 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 :)
>
>
> It's part of an internal project, so I can't release it (or at least, not yet).

Alright.

>
>> Regarding your noop QPaintEngine, what problem have you bumped into
>> that this is solving?
>
>
> This was needed in order to get rendering to work on a Windows system.
> Qt was always erasing the VTK scene by painting over it with the widget's
> background color.  I tried setting the WA_NoSystemBackground flag and
> the WA_PaintOnScreen flag to stop Qt from doing this, but the only trick
> that always worked was replacing the QPaintEngine with a dummy. 

Ah, very interesting. I was porting our app to Windows just today actually. Only just gotten it to build, but can't test running it yet since I'm relegated to VirtualBox until we get a Windows test machine, and the VirtualBox OpenGL driver is not capable enough (ARB_geometry_shader4 missing, probably more). Thanks for the heads up, I may run into this soon.

Elvis

>
>  - David


_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Search the list archives at: http://markmail.org/search/?q=vtk-developers

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers

Loading...