Typing is slow

[franroa]

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

Using Awesome WM with:

OS: ArcoLinux Host: VMware Virtual Platform None Kernel: 6.4.5-arch1-1 Uptime: 59 mins Packages: 1143 (pacman) Shell: bash 5.1.16 Resolution: 1920x1200 WM: awesome Theme: Arc-Dark [GTK2/3] Icons: Sardi-Arc [GTK2/3] Terminal: WezTerm CPU: 12th Gen Intel i7-12850HX (16) GPU: 00:0f.0 VMware SVGA II Adapter Memory: 3.78GiB / 14.53GiB (25%) GPU Driver: vmwgfx CPU Usage: 7% Disk (/): 24G / 147G (17%) Font: Noto Sans 11 [GTK2/3]

WezTerm version

WezTerm-20230712-072601-f4abf8fd

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Typing has some delay, which is not showing up in alacritty

To Reproduce

Just typing some charts

Configuration

no config

Expected Behavior

No response

Logs

No response

Anything else?

No response

[franroa]

I have tried with Manjaro (also based on Arch) and AwesomeWM and is also slow.

[Lassebq]

Can reproduce on wayland, so it's not x11 specific Yes, I tried multiple compositors, it's still slow.

[vimpostor]

Can you be more specific with how slow it is, maybe roughly giving a perceived interactive latency in milliseconds?

According to this blog post wezterm should be competitive with other terminal emulators in regard to latency: https://www.lkhrs.com/blog/2022/07/terminal-latency/

[Lassebq]

• There is no constant input latency, keys are just randomly typed either fast or slowly
• Sometimes it types two characters instead of one
• Even execution times are much slower than in other terminals: Side by side comparison of foot and wezterm:

starship is used to time execution

[vimpostor]

I assume /usr/bin/time --format='%e' ls doesn't output this large time difference?

Also you could try closing all wezterm instances, then start wezterm from another terminal emulator with WEZTERM_LOG=wezterm_gui=trace wezterm and then type ls in wezterm and upload the debug output appearing in the original terminal emulator. That might help with debugging where the latency occurs.

In my case, I get output like this, indicating about 22ms wezterm-internal latency from key-down to render:

Logs

00:12:50.893  DEBUG  wezterm_gui::termwindow                > RawKeyEvent(RawKeyEvent { key: Physical(S), modifiers: NONE, leds: (empty), phys_code: Some(S), raw_code: 39, repeat_count: 1, key_is_down: true, handled: Handled(false) })
00:12:50.893  TRACE  wezterm_gui::termwindow::keyevent      > key_event RawKeyEvent { key: Physical(S), modifiers: NONE, leds: (empty), phys_code: Some(S), raw_code: 39, repeat_count: 1, key_is_down: true, handled: Handled(false) } 
00:12:50.893  DEBUG  wezterm_gui::termwindow                > KeyEvent(KeyEvent { key: Char('s'), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: true, raw: Some(RawKeyEvent { key: Physical(S), modifiers: NONE, leds: (empty), phys_code: Some(S), raw_code: 39, repeat_count: 1, key_is_down: true, handled: Handled(false) }) })
00:12:50.893  TRACE  wezterm_gui::termwindow::keyevent      > key_event KeyEvent { key: Char('s'), modifiers: NONE, leds: (empty), repeat_count: 1, key_is_down: true, raw: Some(RawKeyEvent { key: Physical(S), modifiers: NONE, leds: (empty), phys_code: Some(S), raw_code: 39, repeat_count: 1, key_is_down: true, handled: Handled(false) }) } 
00:12:50.897  DEBUG  wezterm_gui::termwindow                > NeedRepaint
00:12:50.897  TRACE  wezterm_gui::termwindow::render::paint > quad map elapsed 43.651µs
00:12:50.897  TRACE  wezterm_gui::termwindow::render::pane  > lines elapsed 275.873µs
00:12:50.897  DEBUG  wezterm_gui::termwindow::render::paint > paint_impl before call_draw elapsed=474.991µs
00:12:50.897  DEBUG  wezterm_gui::termwindow::render::paint > paint_impl elapsed=662.026µs, fps=3.7842758
00:12:50.899  DEBUG  wezterm_gui::termwindow                > Notification(Any { .. })
00:12:50.914  DEBUG  wezterm_gui::termwindow                > NeedRepaint
00:12:50.914  TRACE  wezterm_gui::termwindow::render::paint > quad map elapsed 31.01µs
00:12:50.915  TRACE  wezterm_gui::termwindow::render        > shape_resolve for cluster len 3 -> elapsed 14.178µs
00:12:50.915  TRACE  wezterm_gui::termwindow::render        > shape_resolve for cluster len 1 -> elapsed 6.285µs
00:12:50.915  TRACE  wezterm_gui::termwindow::render        > shape_resolve for cluster len 2 -> elapsed 83.53µs
00:12:50.915  TRACE  wezterm_gui::termwindow::render::pane  > lines elapsed 592.394µs
00:12:50.915  DEBUG  wezterm_gui::termwindow::render::paint > paint_impl before call_draw elapsed=813.932µs
00:12:50.915  DEBUG  wezterm_gui::termwindow::render::paint > paint_impl elapsed=915.202µs, fps=3.7842758

[wez]

@Lassebq please open your own separate issue. This one is tagged as x11 specific. What you described doesn't sound the same; it's not even talking about typing but execution speed in the terminal.

[wez]

and perhaps you should file two separate issues if you are seeing slow response to typing as well. Please include more information to help quantity and isolate the configuration both in wezterm and your system, such as key repeat and so on.

[Lassebq]

The original issue isn't specific about typing behavior, slow shell execution could be the cause of that too in my opinion, that's why I decided to mention it. I assure you typing on Wayland feels slow and it's not X11 specific. Yes, I tested on X11 side too. Exact same issue.

[herkhinah]

For me typing in wezterm feels very slow when my CPU is under load. It doesn't matter if I'm in an editor or in a shell prompt. Other graphical programs have no typing input lag.

[dotunwrap]

Potentially related (and I will open a separate issue detailing my experience on Arch (X11) when I have time to document and record issues), but I experience more than just input lag and execution lag with wezterm; I actually encounter massive system lag that is not reflected by any resource utilization or consumption to match it. Issue seems to occur after X amount of time with wezterm open, and then I receive massive lag when:

1. Switching workspaces
2. Input on any workspace in any application
3. Executing programs (i.e. btop or nvim)

This is potentially related to application sockets given that I generally have multiple instances of wezterm open at a time (allowing my WM to tile separate windows) rather than using the built in multiplexer and tab/buffer system. That is not confirmed, but was my initial idea when experiencing the issue. Lag persists until all instances of wezterm are closed.

[madnight]

Yesterday, I conducted latency benchmarks for several terminals, including WezTerm, Alacritty, Kitty, Xterm, and others. See https://beuke.org/terminal-latency/

I found that WezTerm scores somewhere in the middle of the field, faster than gnome-terminal but surprisingly slower than Konsole (KDE Terminal). With WezTerm written in Rust + GPU rendering, I have associated top-notch performance in all aspects, including typing latency, hence I'm posting here to create some awareness of a potential issue. I think the issue can be fixed, as far as I know, Alacritty has drastically improved their input latency in recent versions. In Kitty, it is possible to tune the config for lower latency (10 milliseconds is quite decent) and in st, you can recompile with different C header settings and achieve latency in the 5 milliseconds range, similar to Xterm.

[nfejzic]

I found that WezTerm scores somewhere in the middle of the field, faster than gnome-terminal but surprisingly slower than Konsole (KDE Terminal). With WezTerm written in Rust + GPU rendering, I have associated top-notch performance in all aspects, including typing latency, hence I'm posting here to create some awareness of a potential issue.

Hey @madnight, nice post! Did you try adjusting the max_fps of WezTerm when testing? Could you try to measure again with max_fps = 255? I would be interested to see if this changes something.

[madnight]

Sure, here are the results:

WezTerm 67.7 avg with max_fps = 10 WezTerm 26.1 avg wiht max_fps = 75 (my mon has 75hz) WezTerm 21.2 avg with max_fps = 255 WezTerm ERROR with max_fps = 1000 (I guess 255 is max, because it is a byte)

255 FPS does improve the latency, but not as much as I had hoped for. Ideally, I would expect WezTerm to achieve below 10ms latency with some tuning.

[rickypowell]

@madnight Thank you this definitely helped.

[rich-fs]

I think I'm experiencing the same (or similar) issue with Wezterm being super laggy. I've done a quick screencast, not amazing but I think it highlights the issue enough. Top left and side right is alacritty which is smooth. Bottom left is Wezterm and you can see it's very choppy/laggy.

Screencast_20240815_165206.webm

Setting max_fps to 255 improves the issue but doesn't fix it.

[ikouchiha47]

Hi guys. please run the wezterm --config periodic_stat_logging=10 from the terminal, see if its missing some video drivers. Check if OpenGL is using Software or hardware acceleration. Not having the proper video driver set was causing issues in my case. Wezterm's speed is nearly at par with st , and st is pretty fast

[j-morano]

I had the same problem when I had a lot of open terminals. Running wezterm start with the --always-new-process option solved the issue for me. I got the idea from a message that wezterm produced when running it from the terminal:

14:23:10.588  INFO   wezterm_gui > Spawned your command via the existing GUI instance. Use
wezterm start --always-new-process if you do not want this behavior. Result=SpawnResponse
{ tab_id: 86, pane_id: 93, window_id: 63, size: TerminalSize { rows: 24, cols: 80, pixel_width:
640, pixel_height: 384, dpi: 0 } }