Wez Furlong 7caaf136e4 compensate for flickery TUI programs by going slower(!) ... 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		2022-08-21 14:40:06 -07:00
..
src	compensate for flickery TUI programs by going slower(!)	2022-08-21 14:40:06 -07:00
build.rs	colorschemes: expand to include Gogh color schemes	2022-07-10 13:32:17 -07:00
Cargo.toml	cargo update	2022-08-21 08:51:16 -07:00