mirror of
https://github.com/wez/wezterm.git
synced 2024-11-24 07:46:59 +03:00
33f25e9ce6
The tcgetpgrp call appears to have high variance in latency, ranging from 200-700us on my system. If you have 10 tabs and mouse over the tab bar, that's around 7ms spent per frame just figuring out the foreground process; that doesn't include actually extracting the process executable or current working directory paths. This was exacerbated by the mouse move events triggering a tab bar recompute on every pixel of mouse movement. This commit takes the following steps to resolve this: * We now only re-compute the tab bar when the UI item is changed by a mouse movement * A simple single-item cache is now used on unix that allows the caller to proceed quickly with stale-but-probably-still-mostly-accurate data while queuing up an update to a background thread which can absorb the latency. The result of this is that hovering over several tabs in quick succession no longer takes a noticeable length of time to render the hover, but the consequence is that the contents of a given tab may be stale by 300-400ms. I think that trade-off is worth while. We already have a similar trade-off on Windows, although we don't yet do the updates in a different thread on Windows. Perhaps in a follow up commit? refs: https://github.com/wez/wezterm/issues/2991 |
||
|---|---|---|
| .. | ||
| sftp | ||
| auth.rs | ||
| channelwrap.rs | ||
| config.rs | ||
| dirwrap.rs | ||
| filewrap.rs | ||
| host.rs | ||
| lib.rs | ||
| pty.rs | ||
| session.rs | ||
| sessioninner.rs | ||
| sessionwrap.rs | ||
| sftpwrap.rs | ||