Mir

[xmir] Inputs slowing, last event of a stream of events greatly delayed

Bug #1199450 reported by Gerry Boland
106
This bug affects 19 people
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Critical
Daniel van Vugt
mir (Ubuntu)
Fix Released
Critical
Daniel van Vugt

Bug Description

If I type 10 characters quickly, the first 9 come out reasonably fast, but the last after a delay of almost 1/2 a second.

Also if I move mouse rapidly, then stop, mouse cursor stops, then after a few 100ms it jumps a few pixels to final destination.

Have been using XMir continuously for over 6 hours now.

Possibly related to bug: 1199449

Related branches

Gerry Boland (gerboland)
summary: - [xmir] Keyboard input slowing, last character of a spell of typing takes
- 1/2 second to appear
+ [xmir] Inputs slowing, last event of a stream of events greatly delayed
Changed in mir:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Chris Halse Rogers (raof)
Revision history for this message
Gerry Boland (gerboland) wrote :

Having done a fresh boot 3 hours ago, everything was fine until I had a Google hangout. Now the lag is back.

Changed in xmir:
status: New → Triaged
assignee: nobody → Chris Halse Rogers (raof)
Changed in xmir:
importance: Undecided → Medium
Revision history for this message
Gerry Boland (gerboland) wrote :

Using XFCE on Mir, no issue

Revision history for this message
kevin gunn (kgunn72) wrote :

ok i am now seeing this again after last nights update - hadn't had a problem in a week.
1 google hangout last night after rebooting too....
super annoying, must be fixed for 13.10

Changed in xmir:
importance: Medium → Critical
Changed in mir:
importance: Medium → Critical
Revision history for this message
kevin gunn (kgunn72) wrote :

I am noticing lag in my usb mouse click as well

Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

I don't run XMir (as I like to run Mir by itself and this doesn't work currently).

But I occasionally see this behaviour too. (But not - so far - today)

Revision history for this message
Christopher Townsend (townsend) wrote :

I just updated with last night's update and I see this immediately when typing into a terminal. I tried both Gnome Terminal and Terminator with the same result.

Revision history for this message
Gerry Boland (gerboland) wrote :

To update me comment above, still using XFCE on Mir, after a few suspend/resume cycle, the input stream has become a bit erratic. All events gets through eventually - and in the right order, but some events in a close bunch are delayed by up to a second.

Typing this sentence alone is a chore!! And mouse movement is increasingly unpredictable - I move my physical mouse, the cursor waits about 500ms, then hops to where it should be . Then when I stop moving the mouse, again I get that final jump.

And then hang. Can't find anything useful in log files that could help :(

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I wonder if we're just assuming that the lag is in input, because that's how we interact with Mir.

It's possible the lag is in rendering, and that just makes input feel delayed.

Revision history for this message
Chris Halse Rogers (raof) wrote :

I believe that Daniel is correct.

I think that after some trigger we're missing the last Damage event, so the final character is only drawn after the *next* drawing event occurs (you can see this well in a text field with a blinking cursor - the final character will appear when the cursor blinks).

I'll investigate further next week.

Revision history for this message
Chris Halse Rogers (raof) wrote :

On further inspection - we're *not* missing a damage event. When adding counters for our thread-proxy messages, damage events received, and swap_buffers sent XMir definitely receives a Damage event and sends a swap_buffers call in reply. It would appear that the buffers we're submitting have a 1-frame delay between rendering and display.

This could be because XMir is rendering to the wrong buffer, or it could be because Mir is doing something crazy, like triple buffering.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I think I noticed this could happen when I started looking at multi_threaded_compositor.cpp

It looks like the client/session-mediator gives a pulse to tell the compositor a new frame is ready, and the compositor takes the next one off the queue. However this will only work in double-buffering. If you have triple (or more) buffers then that latest frame the client wants to show won't get displayed. There will be a delay of N-2 frames (for N-buffering) as it goes from the back to the front of the queue. The fault (I assume) is then in Mir's compositing logic. Start by looking at multi_threaded_compositor.cpp ...

Revision history for this message
Chris Halse Rogers (raof) wrote :

This is definitely a Mir problem rather than an XMir problem. Instrumenting everything, we find that the (correct) buffer client acquire/submit→compositor acquire/release loop goes from
12:16 <RAOF> ...
12:16 <RAOF> Client sub buffer{3}
12:16 <RAOF> Client acquired buffer{4}
12:16 <RAOF> Compositor acquired buffer{3}
12:16 <RAOF> Compositing buffer{3}
12:16 <RAOF> Client sub buffer{4}
12:16 <RAOF> Compositor released buffer{3}
12:17 <RAOF> ...

to

12:17 <RAOF> ...
12:17 <RAOF> Client acquired buffer{3}
12:17 <RAOF> Client sub buffer{3}
12:17 <RAOF> Compositor acquired buffer{4}
12:17 <RAOF> Compositing buffer{4}
12:17 <RAOF> Compositor released buffer{4}
12:17 <RAOF> Client acquired buffer{4}
12:17 <RAOF> Client sub buffer{4}
12:17 <RAOF> Compositor acquired buffer{3}
12:17 <RAOF> Compositing buffer{3}
12:17 <RAOF> Compositor released buffer{3}
12:17 <RAOF> ...
12:18 <RAOF> At some point in this log we start compositing the N-1'th buffer submitted by the client, rather than the last one.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Linked a branch I'm working on. Early testing suggests it solves this bug.

Revision history for this message
Andrea Corbellini (andrea.corbellini) wrote :

In case this helps somebody: this bug can be greatly noticed if you disable cursor blink in your terminal emulator.
And I can also confirm that the bug is in rendering, not in input.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

While it would be nice if we had a fix just for this bug, no one else is working on it yet. And given my current work seems to fix it, I will loosely take responsibility for the bug.

Changed in mir:
assignee: Chris Halse Rogers (raof) → Daniel van Vugt (vanvugt)
status: Triaged → In Progress
Changed in mir:
assignee: Daniel van Vugt (vanvugt) → nobody
status: In Progress → Triaged
assignee: nobody → Daniel van Vugt (vanvugt)
status: Triaged → In Progress
Changed in xmir:
status: Triaged → Invalid
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir at revision 948, scheduled for release in mir, milestone 0.0.9

Changed in mir:
status: In Progress → Fix Committed
Jono Bacon (jonobacon)
tags: added: flavormirbug
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Not fixed yet. Only one of the two branches required has landed.

Changed in mir:
status: Fix Committed → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package mir - 0.0.8+13.10.20130809.3-0ubuntu1

---------------
mir (0.0.8+13.10.20130809.3-0ubuntu1) saucy; urgency=low

  [ Daniel van Vugt ]
  * Simplify and generalize buffer swapping to support arbitrary numbers
    of: - buffers - compositors - clients This is a unified N-buffers
    algorithm which supports any positive number of buffers, as well as
    dynamically switching between synchronous and asynchronous
    behaviour. So it does everything the existing code does and more.
    The key requirement is to support an arbitrary number of (different)
    simultaneous compositor acquisitions, as is needed for bypass
    support (coming soon). This then leads to the requirement that a
    compositor and a snapshot buffer should be acquired differently.
    Because a snapshot should never consume frames, only observe them.
    On the other hand, a compositior acquire must consume a frame (if
    available) so as to guarantee correct ordering when more than one
    are acquired simultaneously in bypass mode. Also fixes LP: #1199717
    and is half the fix for LP: #1199450. (LP: #1199450, #1199717)

  [ Alan Griffiths ]
  * doc, tools: update instructions for "flipped" image.

  [ Christopher James Halse Rogers ]
  * Split out unversioned Mir platform package to fix upgrades across
    libmirserver SONAME bumps.

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 950
 -- Ubuntu daily release <email address hidden> Fri, 09 Aug 2013 11:14:41 +0000

Changed in mir (Ubuntu):
status: New → Fix Released
Revision history for this message
kevin gunn (kgunn72) wrote :

just approved https://code.launchpad.net/~vanvugt/mir/fix-compositor-lag/+merge/179117
which should be the other part to the solution

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.0.9

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
milestone: none → 0.0.9
no longer affects: xmir
Changed in mir:
status: Fix Committed → Fix Released
Revision history for this message
Anca Emanuel (anca-emanuel) wrote :

Not fixed for me.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Anca,

What versions are your libmirserver* packages and unity-system-compositor?

Revision history for this message
Anca Emanuel (anca-emanuel) wrote :

emanuel@test:~$ apt-cache show libmirserver* | grep Version
Version: 0.0.9+13.10.20130813-0ubuntu1
Version: 0.0.9+13.10.20130813-0ubuntu1
emanuel@test:~$ unity-system-compositor --version
unity-system-compositor 0.0.1

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Anca,

Can you please confirm the version installed (not cached) by querying:
    dpkg -l | grep libmirserver
?

Also, what kind of GPU/driver are you using?

Revision history for this message
Anca Emanuel (anca-emanuel) wrote :

emanuel@test:~$ dpkg -l | grep libmirserver
ii libmirserver1:amd64 0.0.9+13.10.20130813-0ubuntu1 amd64 Display server for Ubuntu - server library
emanuel@test:~$ lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce 8800 GT] (rev a2)
emanuel@test:~$ dpkg -l | grep nouveau
ii libdrm-nouveau2:amd64 2.4.46-1 amd64 Userspace interface to nouveau-specific kernel DRM services -- runtime
ii libdrm-nouveau2:i386 2.4.46-1 i386 Userspace interface to nouveau-specific kernel DRM services -- runtime
ii xserver-xorg-video-nouveau 1:1.0.8-0ubuntu3 amd64 X.Org X server -- Nouveau display driver

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Anca,

I think you might be seeing nouveau-specific pauses/hiccups, which I have seen myself. But those are nouveau-specific.

Can you please log a new bug? At least unless someone with an Intel GPU reports this one is not fixed.

Revision history for this message
Anca Emanuel (anca-emanuel) wrote :

Reported as bug 1212163

Revision history for this message
Gerry Boland (gerboland) wrote :

After over 24 hours of usage, I confirm this is fixed on my Macbook Pro 8,1 with Sandybridge graphics.

Changed in mir (Ubuntu):
assignee: nobody → Daniel van Vugt (vanvugt)
importance: Undecided → Critical
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu Package testing tracker.

A list of all reports related to this bug can be found here:
http://packages.qa.ubuntu.com/qatracker/reports/bugs/1199450

tags: added: package-qa-testing
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.