mirror of
https://github.com/wez/wezterm.git
synced 2024-12-25 22:33:52 +03:00
7caaf136e4
It's not the first time that I've solved a problem by slowing things down... in this situation, a couple of very inefficient TUI programs had flickering outputs in wezterm because they were filling a buffer with a bunch of spaces to erase a screen before sending the main body of their updates in a subsequent buffer chunk. wezterm would render the intervening partially blank frame and appear to flicker. The resolution is to add a small delay (3ms by default) before sending data to the terminal model. If the output is readable in that time we'll accumulate it with the pending set of actions so that the whole batch can be applied "more atomically". Take care: `time cat bigfile` is sensitive to this, so we want to keep the latency as small as possible, and we also want to avoid accumulating actions and only flushing them at the end of the file. We use the existing buffer size (~1MB) as a threshold: we bump a count of the number of input bytes that resulted in the current set of actions, and if that exceeds that buffer size we flush it. refs: https://github.com/wez/wezterm/issues/2443 |
||
|---|---|---|
| .. | ||
| cli | ||
| colorschemes | ||
| config | ||
| examples | ||
| install | ||
| screenshots | ||
| _config.yml | ||
| asciinema-player.css | ||
| asciinema-player.min.js | ||
| book.toml | ||
| changelog.md | ||
| contributing.md | ||
| copymode.md | ||
| custom.css | ||
| escape-sequences.md | ||
| faq.md | ||
| features.md | ||
| help.md | ||
| hyperlinks.md | ||
| imgcat.md | ||
| index.md | ||
| installation.md | ||
| mermaid-init.js | ||
| multiplexing.md | ||
| quickselect.md | ||
| README.markdown | ||
| scrollback.md | ||
| serial.md | ||
| shell-integration.md | ||
| ssh.md | ||
This directory contains the sources for the documentation. Read the generated documentation at: https://wezfurlong.org/wezterm