wezterm doesn't start rendering text until it gets an input

[ExpandingMan]

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

Linux X11

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

qtile

WezTerm version

wezterm 20220808-072538-27b587ef

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

When I launch wezterm the proceses clearly starts (I can see it listed on my bottom bar) but it does not start rendering anything until it gets a keyboard input. What "not rendering anything" means exactly depends somewhat on the window configuration. If it's full screen or nearly full screen I don't see anything, if it's a smaller window it renders the background but no text. It's easy to get passed this bug just by providing inputs, it will start rendering normally immediately, it's just pretty annoying.

It's difficult to diagnose this because it does not happen if I launch wezterm from another terminal (itself or alacritty) which is strange in-and-of itself.

To Reproduce

No response

Configuration

no config

Expected Behavior

wezterm renders prompt on launching

Logs

12:05:09.798  WARN   wezterm_term::terminalstate > unhandled XtermKeyMode OtherKeys Some(2)
12:05:20.140  WARN   wezterm_term::terminalstate > unhandled XtermKeyMode OtherKeys Some(0)

Anything else?

No response

[wez]

It's difficult to diagnose this because it does not happen if I launch wezterm from another terminal (itself or alacritty) which is strange in-and-of itself.

Weird! My suggestion for this sort of issue is to run with debugging turned up for the windowing portion of wezterm by launching it with WEZTERM_LOG=window::os::x11::window=trace,info set in the environment.

You might need to contrive to have qtile set that, or otherwise make a little wrapper script.

The extra info should show up in the log file that wezterm writes out.

[ExpandingMan]

Sorry about this... this is definitely not an issue with wezterm, it's an issue with me apparently having evolved a crazy elaborate setup...

I have a short terminal discovery script in fish which I use to find the appropriate terminal. For god knows what reason, if from qtile you call fish -c term it produces the strange behavior I described above. My solution was to write a Python function for qtile that does the same thing so that fish does not get called when launching a terminal.

So this was a pretty silly problem.

Anyway, thanks for the quick response!

[ExpandingMan]

This is extremely weird. As I said previously I was having this problem apparently due to a really weird thing I had done to launch it. However, I'm seeing this issue again all of a sudden when launching it normally. It might be somehow hardware dependent because I have multiple very similar manjaro setups and I'm only seeing it on one of them.

I did manage to capture the log this time:

10:04:28.173  TRACE  window::os::x11::window > PropertyNotifyEvent _NET_WM_NAME
10:04:28.174  TRACE  window::os::x11::window > PropertyNotifyEvent _NET_WM_ICON
10:04:30.024  TRACE  window::os::x11::window > About to paint, but we're unsure about focus; querying!
10:04:30.024  TRACE  window::os::x11::window > Do I have focus? true
10:04:30.035  TRACE  window::os::x11::window > About to paint, but we're unsure about geometry; querying window_id Window { res_id: 41943043 }!
10:04:30.035  TRACE  window::os::x11::window > geometry is 1920x1052 vs. our initial 800x480
10:04:30.077  TRACE  window::os::x11::window > PropertyNotifyEvent WM_NAME
10:04:30.077  TRACE  window::os::x11::window > PropertyNotifyEvent _NET_WM_NAME
10:04:31.936  TRACE  window::os::x11::window > focus_changed false, flagging geometry as unsure
10:04:31.936  TRACE  window::os::x11::window > Calling focus_change(false)
10:04:31.937  TRACE  window::os::x11::window > About to paint, but we're unsure about geometry; querying window_id Window { res_id: 41943043 }!
10:04:31.937  TRACE  window::os::x11::window > geometry is 1920x1052 vs. our initial 1920x1052
10:04:31.951  TRACE  window::os::x11::window > focus_changed false, flagging geometry as unsure
10:04:31.951  TRACE  window::os::x11::window > focus_changed true, flagging geometry as unsure
10:04:31.951  TRACE  window::os::x11::window > Calling focus_change(true)
10:04:31.952  TRACE  window::os::x11::window > PropertyNotifyEvent _NET_FRAME_EXTENTS
10:04:31.952  TRACE  window::os::x11::window > Ignoring X::ConfigureNotify (1920x1052 dpi=96) because width,height,dpi are unchanged
10:04:31.952  TRACE  window::os::x11::window > PropertyNotifyEvent WM_STATE
10:04:31.953  TRACE  window::os::x11::window > focus_changed false, flagging geometry as unsure
10:04:31.953  TRACE  window::os::x11::window > Calling focus_change(false)
10:04:31.969  TRACE  window::os::x11::window > About to paint, but we're unsure about geometry; querying window_id Window { res_id: 41943043 }!
10:04:31.970  TRACE  window::os::x11::window > geometry is 1920x1052 vs. our initial 1920x1052
10:04:32.402  TRACE  window::os::x11::window > Present::ConfigureNotify: width 1920 -> 2560, height 1052 -> 1412, dpi 96 -> 96
10:04:32.403  TRACE  window::os::x11::window > Ignoring X::ConfigureNotify (2560x1412 dpi=96) because width,height,dpi are unchanged
10:04:32.403  TRACE  window::os::x11::window > expose: 0,0 2560x1412 (0 expose events follow this one)
10:04:32.403  TRACE  window::os::x11::window > PropertyNotifyEvent _NET_FRAME_EXTENTS
10:04:32.481  TRACE  window::os::x11::window > focus_changed false, flagging geometry as unsure
10:04:32.481  TRACE  window::os::x11::window > focus_changed true, flagging geometry as unsure
10:04:32.481  TRACE  window::os::x11::window > Calling focus_change(true)
10:04:32.482  TRACE  window::os::x11::window > About to paint, but we're unsure about geometry; querying window_id Window { res_id: 41943043 }!
10:04:32.482  TRACE  window::os::x11::window > geometry is 2560x1412 vs. our initial 2560x1412
10:04:34.233  TRACE  window::os::x11::window > PropertyNotifyEvent WM_NAME
10:04:34.233  TRACE  window::os::x11::window > PropertyNotifyEvent _NET_WM_NAME

[wez]

If you open the debug overlay (CTRL-SHIFT-L), what does it say about your OpenGL drivers? Please paste here

[ExpandingMan]

OpenGL version: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 4.6.0 NVIDIA 520.56.06

[ExpandingMan]

I've been taking a break from wezterm because I was having difficult-to-diagnose latency issues. However, today I updated to latest and the latency seems significantly reduced and I also have not yet been able to reproduce the issue posted here (though it's tricky because it was intermittent). So it looks like something that has happened in the past month or so has significantly improved the situation on my platforms.

Btw, I see other threads mentioning vulkan, but I do not see it mentioned in the docs. Is there a way to switch to the vulkan renderer? Thanks!

[wez]

re: Vulkan, it's accessible through the new, in-testing webgpu support. This isn't documented and isn't fully baked, and is subject to change.
This issue has details on how to use it:

• WebGPU front_end #2756

[ExpandingMan]

Cool. WebGpu also seems quite fast to me. It seems to have somewhat wonky font-rendering, I guess because of lack of anti-aliasing, but I look forward to see how it develops.

I don't know what happened in the last few weeks but with or without WebGpu the performance situation with wezterm seems to have completely reversed, though I don't have any real ways of benchmarking so it's a little bit hard to tell for sure. It went from having unacceptably slow latency to seeming slightly faster even than kitty, and now appears to be faster than anything except alacritty. Nice work!

Guess I'll have to switch back (really should make it easier to swap terminals in my linux setup).

I'll close this issue for now since I'm still not able to reproduce it.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.