Please consider SRU of "xcb: Compress mouse motion and touch update events"

Bug #1598173 reported by Elvis Stansvik on 2016-07-01
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
qtbase-opensource-src (Ubuntu)
Undecided
Unassigned
Xenial
Undecided
Unassigned

Bug 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 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.

description: updated
Elvis Stansvik (elvstone) wrote :

Would be great if someone could at least respond to this 8+ month old bug.

We're still suffering from this Qt bug, and have to put in lots of ugly workarounds to mitigate it.

I'm not sure, should I subscribe someone else to this, and if so, who?

Dmitry Shachnev (mitya57) wrote :

Elvis: sorry for not responding. Sometimes pinging the bug *is* helpful.

I will not have time to do a SRU in the next days, but I might take a look a bit later if nobody beats me to it. In the meantime, it would help if you could fill the SRU bug template, see https://wiki.ubuntu.com/StableReleaseUpdates#Procedure.

Changed in qtbase-opensource-src (Ubuntu):
status: New → Fix Released
Elvis Stansvik (elvstone) wrote :

Hi Dimitry!

No problem. In fact, I've cherry picked the fix from Qt 5.6 and created an updated package. I'm building it at the moment to test. I'll fill out the SRU template as well, and attach a debdiff if it seems to work OK.

Sorry for not sticking to the SRU procedure to begin with, I know I was a bit busy when I filed this.

Elvis Stansvik (elvstone) wrote :
description: updated
Elvis Stansvik (elvstone) wrote :

Dmitry: I've updated the description with the SRU template. I also attached a test case and a debdiff.

I've tested that the updated package fixes the problem.

description: updated
description: updated
Dmitry Shachnev (mitya57) wrote :

It is in the upload queue now.

Elvis Stansvik (elvstone) wrote :

Excellent. Many thanks!

Elvis Stansvik (elvstone) wrote :

I'm a little unsure what the process is now, should I tag this bug with something? Or just wait until someone comes around to approve the upload?

Dmitry Shachnev (mitya57) wrote :

The latter, wait until someone approves the upload… Maybe also pinging on #ubuntu-release channel will help.

Elvis Stansvik (elvstone) wrote :

I made a couple of pings in #ubuntu-release without reply, but I guess people are just busy :)

Another question though: I can see that there was already another qtbase-opensource-src upload in the queue (5.5.1+dfsg-16ubuntu7.3). Will an approver have to approve that first, or will that one be discarded and 5.5.1+dfsg-16ubuntu7.4 taken directly?

Dmitry Shachnev (mitya57) wrote :

I hope they will just approve the later upload, and both fixes will make it into -proposed and then -updates together.

Elvis Stansvik (elvstone) wrote :

Alright, yes lets hope.

Hello Elvis, or anyone else affected,

Accepted qtbase-opensource-src into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-16ubuntu7.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in qtbase-opensource-src (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed
Elvis Stansvik (elvstone) wrote :

@apw: I've tested the 5.5.1+dfsg-16ubuntu7.4 in xenial-proposed with the test case I attached in comment #4, as well as the Wrapping/Python/vtk/qt/QVTKRenderWindowInteractor.py script in the VTK source, and the problem is fixed.

tags: added: verification-done
removed: verification-needed
Elvis Stansvik (elvstone) wrote :

Do I need to do something more for this to be uploaded to xenial-updates? Should I try to get someone else to test?

Dmitry Shachnev (mitya57) wrote :

The other bug (bug 1380702) got marked as verification-failed, so it cannot migrate, and now we need to get another upload (-16ubuntu7.5) accepted and published (it is in the queue since Thursday).

Sorry for that because that is partially my fault (I did not test my fix for that bug on Trusty properly).

Elvis Stansvik (elvstone) wrote :

Aha, I forgot to check the other bug. No worries. Thanks a lot for all the work Dmitry, looking at that bug I see that it is much more complicated than this one.

tags: added: verification-done-xenial
removed: verification-done
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtbase-opensource-src - 5.5.1+dfsg-16ubuntu7.5

---------------
qtbase-opensource-src (5.5.1+dfsg-16ubuntu7.5) xenial; urgency=medium

  * Backport upstream change to fix behavior of QMenuBar::isNativeMenuBar()
    method (fix_isNativeMenuBar.diff). This should finally fix LP: #1380702.

 -- Dmitry Shachnev <email address hidden> Wed, 03 May 2017 22:22:47 +0300

Changed in qtbase-opensource-src (Ubuntu Xenial):
status: Fix Committed → Fix Released
Elvis Stansvik (elvstone) wrote :

Thank you! Been waiting for this fix for 11 months, and boy does it taste sweet now that it's here :)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers