mouseFlick in testWindowResizeArea is incredibly slow now

Bug #1651580 reported by Daniel d'Andrada
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
unity8 (Ubuntu)
Fix Released
Low
Albert Astals Cid

Bug Description

Regression caused by http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/2730.

Using xenial+overlay.

mouseFlick() in "make testWindowResizeArea" take a long time now.

These are the numbers in my machine:

"""
QDEBUG : qmltestrunner::WindowResizeArea::test_minimumSize() qml: timeStep = 1944.543648263006, (iterations / speed) = 3.3333333333333335
"""

That commit increased the time between mouse moves from 3.3 ms to a whopping 2 secs.

Related branches

Changed in unity8 (Ubuntu):
assignee: nobody → Albert Astals Cid (aacid)
description: updated
Revision history for this message
Albert Astals Cid (aacid) wrote :

On my machine

We're calling
 mouseFlick(fakeWindow, 161, 161, 41, 41, true/*pressMouse*/, true/*releaseMouse*/, 4/*speed*/, 20/*iterations*/);

and the documentation says
// speed is in pixels/second

We have to travel a distance of sqrt((161-41)*(161-41) + (161-41)*(161-41)) = 120 pixels

Since we told it we want to travel at 4 pixels per second, the total time has to be 30 seconds, since we told it we wan 20 iterations, it'll wait 1.5 seconds between mouse moves.

So previously was broken and now does what it was told to do.

I don't see the bug (other than the mouseFlick call being wrong at passing such a slow speed if you want)

Revision history for this message
Daniel d'Andrada (dandrader) wrote :

Changing the call parameters in the test is fine. Whatever it takes to get mouse flicks in testWindowResizeArea to be reasonable again. Rephrased bug title accordingly.

Saw that similar adjustments have been made to other tests in revision 2730.

summary: - UnityTestCase.mouseFlick is incredibly slow now
+ mouseFlick in testWindowResizeArea is incredibly slow now
Changed in unity8 (Ubuntu):
status: New → In Progress
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity8 - 8.15+17.04.20170110.4-0ubuntu1

---------------
unity8 (8.15+17.04.20170110.4-0ubuntu1) zesty; urgency=medium

  [ Albert Astals Cid ]
  * Give focus to one of the buttons of the dialog
  * tst_WindowResizeArea: Use default values for mouseFlick speed and
    iterations (LP: #1651580)
  * Require Qt 5.6 & misc fixes

  [ Daniel van Vugt ]
  * Deprecate usage of Mir's input resampling, instead opting for: (LP:
    #1497105, #1591328)

  [ Josh Arenson ]
  * Allow the scopes list to automatically scroll when a scope is being
    dragged past the bounds of the screen. (LP: #1575319)

  [ Lukáš Tinkl ]
  * Fix touch window controls being unreachable when the overlay is
    being displayed (LP: #1648167)
  * Fixup paths for window state storage in snappy environment
  * Add Unity.Platform mock for our tests (LP: #1655336)

  [ Michael Zanetti ]
  * PreviewRatingInput: Use displayText instead of text to
    enable/disable the Send button (LP: #1595910)
  * Add a D-Bus interface to control some debug facilities on the fly
  * some launcher workarounds for the snapping

  [ Michał Sawicz ]
  * Nuke leftover Platform in IndicatorsManager

  [ Nick Dedekind ]
  * Added registry for application menus

  [ Michael Terry, Nick Dedekind ]
  * Run the qmluitests.sh autopkg test against the installed package.

  [ Michał Sawicz, Nick Dedekind ]
  * Application menus

  [ Rodney Dawes ]
  * Remove the payments widget and dependency on libpay as no longer
    needed.

 -- Michał Sawicz <email address hidden> Tue, 10 Jan 2017 14:48:42 +0000

Changed in unity8 (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.