Multimonitor startup delay on X11

[axgkl]

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

Linux X11

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

dwm

WezTerm version

wezterm 20240701-070926-69686f45 (also wezterm 20240203-110809-5046fc22)

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

Just additional infos to the startup delay, maybe useful for you (?)
Please close this if its not a bug / not helpful.

Problem

• Fast start on single laptop monitor.
• Significant delay (~half a second), when hdmi monitor is attached (even when started on the same laptop monitor)

See also: #2339 and #2073. My xrandr is fast.

Test Setup

Ran these, with hdmi cable plugged in (slow) and pulled out (fast):

WEZTERM_LOG=trace /usr/bin/wezterm --config-file ./exitconf.lua 2>&1 | tee wez_perf

with

$ cat exitconf.lua
return { default_prog = { "/usr/bin/sleep", "0" },}

Then I normalized the timestamps, to show the offset from 0, not the absolute time.

Findings

1. Nearly half a second difference:

$ tail -n 1 wez_perf_hdmi
0.528  TRACE  wezterm_gui::frontend              > Mux is now empty, terminate gui
$ tail -n 1 wez_perf_no_hdmi
0.121  TRACE  wezterm_gui::frontend              > Mux is now empty, terminate gui

2. No sign. deviation between app image and fedora rpm

3. No sign. deviation between stable and nightly

4. Looking into the perf files, I noticed these:

Discussion

0. At start both report loading the config
1. Both run equally fast until (including) RequestedWindowGeometry.
2. The fast single monitor version continues immediately with window::connection Screens { main: ScreenInfo .... (note: I just pulled the hdmi cable, w/o reconfiguring the monitors, which explains why HDMI is still reported by ScreenInfo)
3. The slow hdmi version continues with two times loading again the config. E.g. 0.206 🟥DEBUG config > paths "." changed, reload config, ...) (note: I marked that with 🟥 in the screenshot) - and looses 0.4 seconds until Screens is showing up.

I don't know, if ScreenInfo would come faster, if you could prevent that 2x reloading of the config - or if it does anyway not matter and X11 is just that slow delivering the info. If so, maybe you could allow to specify it, for wezterm, in the config file? Just an idea which I would gladly accept if startup would be as fast as single monitor, then 😊

The 2 Testfiles are attached.

Thanks for wezterm!

wezperf.zip

To Reproduce

See above test setup

Configuration

See above - test setup.

Expected Behavior

Avoid loading the config 2 times, maybe that makes multimonitor X11 starts 0.4 secs faster (?)

Logs

See above the zip of the trace perf

Anything else?

No response

[wez]

Try putting your test configuration file in a directory that isn't modified during startup. That will eliminate the extraneous configuration reloads.

In general: there isn't much we can do about X11/XRandR being slow at returning information on startup, so I'm not sure that there is really anything to fix here.

[axgkl]

@wez

Try putting your test configuration file in a directory that isn't modified during startup. That will eliminate the extraneous configuration reloads.

🤦‍♂️ I'm sorry, did not consider that. In deed, the reloads are gone now.

So it's really X11, which costs us 0.4 secs at startup just to deliver that ScreenInfo.

0.05  TRACE  wezterm_gui::termwindow            > RequestedWindowGeometry { width: Pixels(820.0), height: Pixels(583.0), x: None, y: None, origin: ScreenCoordinateSystem }
0.42  TRACE  window::connection                 > Screens { main: ScreenInfo { name: "HDMI-1", rect: Rect(3840x2160 at (0, 0)), scale: 1.0, max_fps: Some(30), effective_dpi: Some(96.0) }...

And I guess that info can't be hardcoded in the config file.

So yeah, thanks Wez!

Finally the first reason to consider wayland ✨

[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.