Subject: You can make latency lower

From: Daniel van Vugt <[email-masked]>
Date: Thu, 14 May 2015 16:40:03 +0800

Hey all,

The Mir team has a few separate efforts under way that will reduce 
latency/lag in the future. This is great and you'll see them announced 
when eventually released but in the mean time you should remember a 
well-written app/toolkit doesn't need all of the coming enhancements. So 
here are some guidelines on writing low latency code that you can use 
right now...

1. Process input events at a different rate to graphics rendering. It's 
tempting to try and draw a new frame every time some new input event 
comes in, but in the vast majority of cases input devices generate 
events much faster than any monitor will refresh. So if you try to match 
1:1 each input event to a new frame you will forever be displaying 
frames based on old input data (in fact progressively older and older 
without bounds). A workaround is in place in Mir to mitigate this 
problem by resampling input down to 59Hz, but if your app is well 
written with asynchronous input processing you can disable that with 
environment MIR_CLIENT_INPUT_RATE=0 to get the full rate raw input stream.

2. Don't rely on vsync for timing. Of course, that's a generally good 
guideline as different monitors will give you different refresh rates. 
But if you use the standard default setting eglSwapInterval(d,1) then 
your average case latency to the compositor is still N-1 frames (where N 
is the number of buffers allocated, usually 3), hence 2 x 16.6ms = 33ms.
   Using a swap interval of zero however makes things more interesting. 
You can respond to input events and render new frames based on that 
newer input data without having to wait a full 16ms each time. So a well 
written app (sub-1ms render time with swap interval zero) with a fast 
input device effectively could have close to 1ms from input to render 
completion. That's profoundly faster than 33ms and you will notice it. 
Of course, be careful to only wake up when you need to respond to input 
or else battery life will suffer.

3. When testing latency use a mouse first and not a touch screen. It's a 
sad fact of life that touch screens are almost all slow. They add tens, 
sometimes even hundreds of milliseconds of lag to the experience. So if 
you want to check you're doing things well, better to test with a mouse. 
Then just be aware that touch screen events will always arrive slower 
than mouse events.

- Daniel