| 2016-07-01 13:59:48 |
Elvis Stansvik |
bug |
|
|
added bug |
| 2016-07-01 14:00:38 |
Elvis Stansvik |
description |
A fix for QTBUG-40889 was worked out and submitted at
https://codereview.qt-project.org/#/c/115531/
but due to coming in a bit late, was moved to Qt 5.6
https://codereview.qt-project.org/#/c/126136/
The bug is about mouse motion event compression malfunctioning, and it has grave consequences for some applications, where the flood of events make rendering sluggish (e.g. anything based on VTK, but probably others).
ParaView developer Ben Boeckel has tried the patch [2] and confirm it fixes rendering/interaction in VTK applications.
It is not possible to work around the bug at the application level in a satisfactory way, only by resorting to timer-based rendering.
I suggest an SRU to patch the Ubuntu Qt package with the patch that was originally meant for the 5.x branch (first URL above). The patch was later integrated in 5.6 where it has been well tested.
[1] https://bugreports.qt.io/browse/QTBUG-40889
[2] http://vtk.1045678.n5.nabble.com/Delayed-mouse-interaction-due-to-event-loop-bug-in-Qt5-tp5730474p5732870.html |
A fix for QTBUG-40889 was worked out and submitted at
https://codereview.qt-project.org/#/c/115531/
but due to coming in a bit late, was moved to Qt 5.6
https://codereview.qt-project.org/#/c/126136/
The bug is about mouse motion event compression malfunctioning, and it has grave consequences for some applications, where the flood of events make rendering sluggish (e.g. anything based on VTK, but probably others).
ParaView developer Ben Boeckel has tried the patch [2] against 5.5 and confirmed it fixes rendering/interaction in VTK applications.
It is not possible to work around the bug at the application level in a satisfactory way, only by resorting to timer-based rendering.
I suggest an SRU to patch the Ubuntu Qt package with the patch that was originally meant for the 5.x branch (first URL above). The patch was later integrated in 5.6 where it has been well tested.
[1] https://bugreports.qt.io/browse/QTBUG-40889
[2] http://vtk.1045678.n5.nabble.com/Delayed-mouse-interaction-due-to-event-loop-bug-in-Qt5-tp5730474p5732870.html |
|
| 2017-03-20 15:27:43 |
Dmitry Shachnev |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-03-20 15:27:43 |
Dmitry Shachnev |
bug task added |
|
qtbase-opensource-src (Ubuntu Xenial) |
|
| 2017-03-20 15:27:56 |
Dmitry Shachnev |
qtbase-opensource-src (Ubuntu): status |
New |
Fix Released |
|
| 2017-03-20 20:16:32 |
Elvis Stansvik |
description |
A fix for QTBUG-40889 was worked out and submitted at
https://codereview.qt-project.org/#/c/115531/
but due to coming in a bit late, was moved to Qt 5.6
https://codereview.qt-project.org/#/c/126136/
The bug is about mouse motion event compression malfunctioning, and it has grave consequences for some applications, where the flood of events make rendering sluggish (e.g. anything based on VTK, but probably others).
ParaView developer Ben Boeckel has tried the patch [2] against 5.5 and confirmed it fixes rendering/interaction in VTK applications.
It is not possible to work around the bug at the application level in a satisfactory way, only by resorting to timer-based rendering.
I suggest an SRU to patch the Ubuntu Qt package with the patch that was originally meant for the 5.x branch (first URL above). The patch was later integrated in 5.6 where it has been well tested.
[1] https://bugreports.qt.io/browse/QTBUG-40889
[2] http://vtk.1045678.n5.nabble.com/Delayed-mouse-interaction-due-to-event-loop-bug-in-Qt5-tp5730474p5732870.html |
Mouse event compression stopped working in Qt 5, a regression from Qt 4:
https://bugreports.qt.io/browse/QTBUG-40889
The bug was fixed in Qt 5.6 https://codereview.qt-project.org/#/c/126136/ where it has been thoroughly tested by now.
Attached is a debdiff against 5.5.1+dfsg-16ubuntu7.2 which includes a backport of the 5.6 patch (only one trivial hunk failed, which was easily fixed).
[Impact]
The bug affects any program that relies on the event compression Qt normally does. For example, VTK programs (ParaView, Tomviz, ...) do their rendering in response to mouse events during camera movements, and with event compression at the Qt level suddenly gone, camera movements become very slow, since the application is now flooded with mouse events and the rendering lags behind.
The problem is not limited to these programs however; it can be observed by simply putting two regular, slightly slow-to-render, widgets into a QSplitter and moving the splitter handle. The result is a syrup-like experience as the widgets try to keep up with the onslaught of resize events due to the lack of mouse event compression.
[Test Case]
The attached test application can be used to check if event compression is functioning. It performs some artificial work on each mouse move and prints a message. Click and drag the mouse a little. After releasing the mouse, you'll notice that the printouts keeps coming for quite a while, as the program is catching up with the flood of events.
With the attached patch (and with Qt 4), the problem is gone - the mouse event stream is compressed and the printouts are no longer lagging behind.
[Regression Potential]
There's a small risk that some applications have made workarounds for the faulty behavior, and that unwanted behavior is introduced if this bug is fixed. But chances are high that such workarounds will keep working, as the obvious workaround is to do timer based rendering instead of event based. The workarounds will then simply become unnecessary, but shouldn't cause problems.
I'm asking for someone to nominate this bug for an SRU of 16.04 LTS. |
|
| 2017-03-20 20:17:25 |
Elvis Stansvik |
attachment added |
|
Test case to demonstrate the bug https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173/+attachment/4841177/+files/qtbug40889.zip |
|
| 2017-03-20 20:18:59 |
Elvis Stansvik |
attachment added |
|
debdiff for 5.5.1+dfsg-16ubuntu7.3 with backported fix from Qt 5.6 https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173/+attachment/4841178/+files/fix-qtbug-40889.debdiff |
|
| 2017-03-20 20:28:14 |
Elvis Stansvik |
description |
Mouse event compression stopped working in Qt 5, a regression from Qt 4:
https://bugreports.qt.io/browse/QTBUG-40889
The bug was fixed in Qt 5.6 https://codereview.qt-project.org/#/c/126136/ where it has been thoroughly tested by now.
Attached is a debdiff against 5.5.1+dfsg-16ubuntu7.2 which includes a backport of the 5.6 patch (only one trivial hunk failed, which was easily fixed).
[Impact]
The bug affects any program that relies on the event compression Qt normally does. For example, VTK programs (ParaView, Tomviz, ...) do their rendering in response to mouse events during camera movements, and with event compression at the Qt level suddenly gone, camera movements become very slow, since the application is now flooded with mouse events and the rendering lags behind.
The problem is not limited to these programs however; it can be observed by simply putting two regular, slightly slow-to-render, widgets into a QSplitter and moving the splitter handle. The result is a syrup-like experience as the widgets try to keep up with the onslaught of resize events due to the lack of mouse event compression.
[Test Case]
The attached test application can be used to check if event compression is functioning. It performs some artificial work on each mouse move and prints a message. Click and drag the mouse a little. After releasing the mouse, you'll notice that the printouts keeps coming for quite a while, as the program is catching up with the flood of events.
With the attached patch (and with Qt 4), the problem is gone - the mouse event stream is compressed and the printouts are no longer lagging behind.
[Regression Potential]
There's a small risk that some applications have made workarounds for the faulty behavior, and that unwanted behavior is introduced if this bug is fixed. But chances are high that such workarounds will keep working, as the obvious workaround is to do timer based rendering instead of event based. The workarounds will then simply become unnecessary, but shouldn't cause problems.
I'm asking for someone to nominate this bug for an SRU of 16.04 LTS. |
Mouse event compression stopped working in Qt 5, a regression from Qt 4:
https://bugreports.qt.io/browse/QTBUG-40889
The bug was fixed in Qt 5.6 https://codereview.qt-project.org/#/c/126136/ where the fix has been thoroughly tested by now.
Attached is a debdiff against 5.5.1+dfsg-16ubuntu7.2 which includes a backport of the 5.6 patch (only one trivial hunk failed, which was easily fixed).
[Impact]
The bug affects any program that relies on the event compression Qt normally does. For example, VTK programs (ParaView, Tomviz, ...) do their rendering in response to mouse events during camera movements, and with event compression at the Qt level suddenly gone, camera movements become very slow, since the application is now flooded with mouse events and the rendering lags behind.
The problem is not limited to these programs however; it can be observed by simply putting two regular, slightly slow-to-render, widgets into a QSplitter and moving the splitter handle. The result is a syrup-like experience as the widgets try to keep up with the onslaught of resize events due to the lack of mouse event compression.
[Test Case]
The attached test application can be used to check if event compression is functioning. It performs some artificial work on each mouse move and prints a message. Click and drag the mouse a little. After releasing the mouse, you'll notice that the printouts keeps coming for quite a while, as the program is catching up with the flood of events.
With the attached patch (and with Qt 4), the problem is gone - the mouse event stream is compressed and the printouts are no longer lagging behind.
[Regression Potential]
There's a small risk that some applications have made workarounds for the faulty behavior, and that unwanted behavior is introduced if this bug is fixed. But chances are high that such workarounds will keep working, as the obvious workaround is to do timer based rendering instead of event based. The workarounds will then simply become unnecessary, but shouldn't cause problems.
I'm asking for someone to nominate this bug for an SRU of 16.04 LTS. |
|
| 2017-03-20 20:28:55 |
Elvis Stansvik |
description |
Mouse event compression stopped working in Qt 5, a regression from Qt 4:
https://bugreports.qt.io/browse/QTBUG-40889
The bug was fixed in Qt 5.6 https://codereview.qt-project.org/#/c/126136/ where the fix has been thoroughly tested by now.
Attached is a debdiff against 5.5.1+dfsg-16ubuntu7.2 which includes a backport of the 5.6 patch (only one trivial hunk failed, which was easily fixed).
[Impact]
The bug affects any program that relies on the event compression Qt normally does. For example, VTK programs (ParaView, Tomviz, ...) do their rendering in response to mouse events during camera movements, and with event compression at the Qt level suddenly gone, camera movements become very slow, since the application is now flooded with mouse events and the rendering lags behind.
The problem is not limited to these programs however; it can be observed by simply putting two regular, slightly slow-to-render, widgets into a QSplitter and moving the splitter handle. The result is a syrup-like experience as the widgets try to keep up with the onslaught of resize events due to the lack of mouse event compression.
[Test Case]
The attached test application can be used to check if event compression is functioning. It performs some artificial work on each mouse move and prints a message. Click and drag the mouse a little. After releasing the mouse, you'll notice that the printouts keeps coming for quite a while, as the program is catching up with the flood of events.
With the attached patch (and with Qt 4), the problem is gone - the mouse event stream is compressed and the printouts are no longer lagging behind.
[Regression Potential]
There's a small risk that some applications have made workarounds for the faulty behavior, and that unwanted behavior is introduced if this bug is fixed. But chances are high that such workarounds will keep working, as the obvious workaround is to do timer based rendering instead of event based. The workarounds will then simply become unnecessary, but shouldn't cause problems.
I'm asking for someone to nominate this bug for an SRU of 16.04 LTS. |
Mouse event compression stopped working in Qt 5, a regression from Qt 4:
https://bugreports.qt.io/browse/QTBUG-40889
The bug was fixed in Qt 5.6 https://codereview.qt-project.org/#/c/126136/ where the fix has been thoroughly tested by now.
Attached is a debdiff against 5.5.1+dfsg-16ubuntu7.2 which includes a backport of the 5.6 patch (only one trivial hunk failed, which was easily fixed).
[Impact]
The bug affects any program that relies on the event compression Qt normally performs. For example, VTK programs (ParaView, Tomviz, ...) do their rendering in response to mouse events during camera movements, and with event compression at the Qt level suddenly gone, camera movements become very slow, since the application is now flooded with mouse events and the rendering lags behind.
The problem is not limited to these programs however; it can be observed by simply putting two regular, slightly slow-to-render, widgets into a QSplitter and moving the splitter handle. The result is a syrup-like experience as the widgets try to keep up with the onslaught of resize events due to the lack of mouse event compression.
[Test Case]
The attached test application can be used to check if event compression is functioning. It performs some artificial work on each mouse move and prints a message. Click and drag the mouse a little. After releasing the mouse, you'll notice that the printouts keeps coming for quite a while, as the program is catching up with the flood of events.
With the attached patch (and with Qt 4), the problem is gone - the mouse event stream is compressed and the printouts are no longer lagging behind.
[Regression Potential]
There's a small risk that some applications have made workarounds for the faulty behavior, and that unwanted behavior is introduced if this bug is fixed. But chances are high that such workarounds will keep working, as the obvious workaround is to do timer based rendering instead of event based. The workarounds will then simply become unnecessary, but shouldn't cause problems.
I'm asking for someone to nominate this bug for an SRU of 16.04 LTS. |
|
| 2017-04-24 06:24:10 |
Andy Whitcroft |
qtbase-opensource-src (Ubuntu Xenial): status |
New |
Fix Committed |
|
| 2017-04-24 06:24:12 |
Andy Whitcroft |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2017-04-24 06:24:16 |
Andy Whitcroft |
bug |
|
|
added subscriber SRU Verification |
| 2017-04-24 06:24:23 |
Andy Whitcroft |
tags |
|
verification-needed |
|
| 2017-04-24 11:09:37 |
Elvis Stansvik |
tags |
verification-needed |
verification-done |
|
| 2017-06-09 16:39:25 |
Łukasz Zemczak |
tags |
verification-done |
verification-done-xenial |
|
| 2017-06-12 18:56:30 |
Launchpad Janitor |
qtbase-opensource-src (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
