New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve input latency #673

Open
jwilm opened this Issue Jul 18, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@jwilm
Owner

jwilm commented Jul 18, 2017

First, for background, please see https://danluu.com/term-latency/

In the case of Alacritty, we have a worst-case latency (assuming reasonable draw times) of 3 VBLANK intervals. Here's the scenario:

  1. Input arrives just after a VBI, and a latency of VBI - draw_time is added
  2. After swapping buffers, input is handled. The key press event is sent to the program running within Alacritty, but a response won't be available until after the next VBI. One more VBI of latency is added.
  3. After swapping buffers again, the shell (for example) would have told the terminal to display a character. After drawing, we must wait one more VBI to see the result.

In total, that's 3 * VBI - draw_time. In a perfect world, draw_time is zero, and our worst case input latency is 3 VBI.

This can be resolved by moving the rendering to a separate thread. Certain windowing APIs require input processing to occur on the main thread, so input processing must stay in place. In the same scenario as described above, we can reduce the worst case to 2 VBLANK intervals. With input processing on its own thread, it no longer needs to wait for swap_buffers to return. Key press events can be sent to the terminal immediately, which means any drawing the child program does will be available to draw on the very next frame.

@restfuladi

This comment has been minimized.

Show comment
Hide comment
@restfuladi

restfuladi Aug 13, 2017

Would something like Nvidia's Fast Sync help in this case?

restfuladi commented Aug 13, 2017

Would something like Nvidia's Fast Sync help in this case?

@osa1

This comment has been minimized.

Show comment
Hide comment
@osa1

osa1 Sep 19, 2018

I wrote this on the /r/rust thread and someone asked me to file a ticket but I thought a comment in the existing ticket may be better, so here it is.

On my setup there's noticeable input lag in Alacritty, compared to other terminals like st and konsole. I don't know how to measure it and I'm happy to help with getting some numbers/debugging/profiling etc.

Here's how I feel the lag: when I keep a key pressed so that it repeats (e.g. arrow keys or hjkl in vim), after I stop pressing the key the key repeats one or more times, whereas in other terminals key repeat immediately stops. This makes alacritty feel like it's coming behind my actual key presses (as if key press events are waiting to be handled but alacritty is not fast enough, so even after I stop pressing it handles old key press events).

My key repeat settings: 260ms repeat delay and repeat speed of 55 key strokes per second (xset r rate 260 55).

Secondly, when typing I notice that it takes slightly more time in alacritty to see the letters appear. But this isn't as serious issue as and I'd probably get used to this if the other issue is fixed.

The problem with performance and latency problems is that everything is fast enough until you see something faster (e.g. 30 FPS in games was acceptable years ago, now anything below 60 FPS seems laggy), so it's hard to talk about these issues. Let me know if I can provide anything to diagnose the problem.

osa1 commented Sep 19, 2018

I wrote this on the /r/rust thread and someone asked me to file a ticket but I thought a comment in the existing ticket may be better, so here it is.

On my setup there's noticeable input lag in Alacritty, compared to other terminals like st and konsole. I don't know how to measure it and I'm happy to help with getting some numbers/debugging/profiling etc.

Here's how I feel the lag: when I keep a key pressed so that it repeats (e.g. arrow keys or hjkl in vim), after I stop pressing the key the key repeats one or more times, whereas in other terminals key repeat immediately stops. This makes alacritty feel like it's coming behind my actual key presses (as if key press events are waiting to be handled but alacritty is not fast enough, so even after I stop pressing it handles old key press events).

My key repeat settings: 260ms repeat delay and repeat speed of 55 key strokes per second (xset r rate 260 55).

Secondly, when typing I notice that it takes slightly more time in alacritty to see the letters appear. But this isn't as serious issue as and I'd probably get used to this if the other issue is fixed.

The problem with performance and latency problems is that everything is fast enough until you see something faster (e.g. 30 FPS in games was acceptable years ago, now anything below 60 FPS seems laggy), so it's hard to talk about these issues. Let me know if I can provide anything to diagnose the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment