Skip to content

WIP: clutter/stage: Process input events out of phase with redraws [performance]

Daniel van Vugt requested to merge vanvugt/mutter:input-out-of-phase into master

This ensures clients have a reasonable chance of responding before the next server redraw and will appear to have one frame lower input latency than before.

This doesn't change the frequency of input events. The frequency is still that of the refresh rate. This only changes the phase, or time within each frame when they are flushed.

Previously input events would always be queued and then processed on the next server redraw. However, because the events weren't emitted until the server redraw the client redraw didn't start until that same time, at which it was too late to make it into the same server redraw:

      Frame  ---0---------1---------2---------3---
                     |    |         |       |
                 First    Server    Server  Output of first
                 input    redraw    redraw  input event visible
                 event    |         :   
                          Client....:
                          redraw
    
                     |<-------------------->| Latency

Now we emit the first event immediately:

      Frame  ---0---------1---------2---
                     |    |       |   
                 First    Server  Output of first
                 input    redraw  input event visible
                 event    :   
                     |    :   
                Client....:
                redraw
    
                     |<---------->| Latency

Later events will still get queued and compressed but only if they arrive faster than the display's refresh rate.

(average latency before) = (half input interval) + (one frame) + (render)
(average latency after) = (half input interval) + (render)
(average latency after) = (average latency before) - (one frame)

Prerequisite: !651 (closed) (included here)

Replaces !168 (closed). Though this arguably doesn't perform quite as well as !168 (closed) it does avoid the issues that are blocking !168 (closed).

Edited by Jeff Fortin

Merge request reports