mirror of
https://github.com/wez/wezterm.git
synced 2024-11-23 15:04:36 +03:00
ba309931a3
This slightly improves the startup time of wezterm. Right now we query the portal appearance value again over dbus every time that we access it, for example every time that the user calls wezterm.gui.get_appearance() from the Lua interface. Queries over dbus are slow, they usually take a few milliseconds to complete, for example on my system a portal query over dbus takes around 2 milliseconds to complete. Wezterm also automatically calls the portal during its own internal x11/wayland connection initialization, thus right now wezterm queries the appearance portal setting n+1 times on startup, where n is the number of times that the user calls get_appearance() from the config. To fix this problem, we simply cache the portal appearance. Thus this patch decreases the startup time by 2ms for users that configure wezterm to follow the global system theme and potentially by more for users that call get_appearance() in inflational amounts. With the naive implementation wezterm would be subject to the following race condition: 1. wezterm calls get_appearance() and caches the value 2. System-wide dark mode changes 3. wezterm subscribes to portal notifications In that scenario wezterm would miss the dark mode switch entirely and would cache the wrong value until the dark mode switches again after wezterm subscribed. To fix this race condition we call read_setting() again **after** we have subscribed just to be on the safe side. Note that while this still introduces a second "redundant" dbus query for the same value, this time it does not actually block start up since it happens in another thread. refs: #2258 |
||
|---|---|---|
| .. | ||
| examples | ||
| src | ||
| build.rs | ||
| Cargo.toml | ||
| LICENSE.md | ||