Last dash frame not posted to display

Bug #1353374 reported by Andrea Cimitan
44
This bug affects 7 people
Affects Status Importance Assigned to Milestone
qtmir (Ubuntu)
Fix Released
High
Daniel d'Andrada

Bug Description

With the new dash as app, if I swipe to right from an app it goes back to dash but not on the app scope (or well it seems the index changes internally, because if I then flick right or left to switch scope I an see it jumps from the app scope)

To reproduce:

- go to video scope
- reveal launcher and open system settings
- swipe to right

expected result:
* app scope

current result:
* video scope (if you flick left from here you go to scopes scope, and you see jumping from app scope)

Related branches

Revision history for this message
Andrea Cimitan (cimi) wrote :

We discovered that in reality it switches to the app scope, but visually we didn't get the last frame. We see the video scope but tapping on the dash opens apps from the app scope

Michał Sawicz (saviq)
Changed in unity8:
status: New → Incomplete
Revision history for this message
Michał Sawicz (saviq) wrote :

This seems related to bug #1319907, but that was fixed, we need to have a close look on where is the frame lost.

Revision history for this message
Michał Sawicz (saviq) wrote :

Possibly same cause: bug #1351281

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mir (Ubuntu):
status: New → Confirmed
Changed in qtmir (Ubuntu):
status: New → Confirmed
Michał Sawicz (saviq)
summary: - Regression - swipe to right does not switch back to app scope
+ Last dash frame not posted to display
Changed in qtmir (Ubuntu):
assignee: nobody → Daniel d'Andrada (dandrader)
Changed in unity8:
assignee: nobody → Daniel d'Andrada (dandrader)
Changed in qtmir (Ubuntu):
status: Confirmed → In Progress
Changed in unity8:
status: Incomplete → In Progress
Changed in unity8:
status: In Progress → Incomplete
Changed in qtmir (Ubuntu):
status: In Progress → Confirmed
Changed in unity8:
status: Incomplete → In Progress
Changed in qtmir (Ubuntu):
status: Confirmed → In Progress
affects: mir (Ubuntu) → mir
Changed in mir:
status: Confirmed → Incomplete
no longer affects: unity8
no longer affects: mir
Gerry Boland (gerboland)
Changed in qtmir (Ubuntu):
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qtmir - 0.4.1+14.10.20140815-0ubuntu1

---------------
qtmir (0.4.1+14.10.20140815-0ubuntu1) utopic; urgency=low

  [ Daniel d'Andrada ]
  * MirSurfaceItem: always try to consume new mir frames Otherwise those
    frames will get dropped and MirSurfaceItem will therefore never use
    them, being left displaying an old, stale, frame until the
    application renders again.This could happen for instance if an
    application was rendering between the time the Application object
    goes to Suspended state and the actual process getting SIG_STOPPED
    (ie, suspended for real). Frames rendered in this interval were
    getting dropped and once that app was resumed and its MirSurfaceItem
    brought to front the user would see an old stale frame until some
    new event caused the application to render a new frame (e.g. an
    input event) (LP: #1353374)
 -- Ubuntu daily release <email address hidden> Fri, 15 Aug 2014 17:13:24 +0000

Changed in qtmir (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.