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

[Gerry Boland]

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

[Gerry Boland (gerboland)]

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

[Gerry Boland (gerboland)]

Using XFCE on Mir, no issue

[kevin gunn (kgunn72)]

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

[kevin gunn (kgunn72)]

I am noticing lag in my usb mouse click as well

[Alan Griffiths (alan-griffiths)]

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)

[Christopher Townsend (townsend)]

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.

[Gerry Boland (gerboland)]

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 :(

[Daniel van Vugt (vanvugt)]

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.

[Chris Halse Rogers (raof)]

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.

[Chris Halse Rogers (raof)]

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.

[Daniel van Vugt (vanvugt)]

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

[Chris Halse Rogers (raof)]

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.

[Daniel van Vugt (vanvugt)]

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

[Andrea Corbellini (andrea.corbellini)]

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.

[Daniel van Vugt (vanvugt)]

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.

[PS Jenkins bot (ps-jenkins)]

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

[Daniel van Vugt (vanvugt)]

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

[Launchpad Janitor (janitor)]

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

[kevin gunn (kgunn72)]

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

[PS Jenkins bot (ps-jenkins)]

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

[Anca Emanuel (anca-emanuel)]

Not fixed for me.

[Daniel van Vugt (vanvugt)]

Anca,

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

[Anca Emanuel (anca-emanuel)]

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

[Daniel van Vugt (vanvugt)]

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?

[Anca Emanuel (anca-emanuel)]

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

[Daniel van Vugt (vanvugt)]

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.

[Anca Emanuel (anca-emanuel)]

Reported as bug 1212163

[Gerry Boland (gerboland)]

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