8454bbe183
The input/pty processing loop previously consumed input on a channel and hit the rendering when the queue became empty. This had a couple of problems 1. It was possible to be overwhelmed with input and not give the renderer an opportunity to update the screen. This gave the appearance of locking up. 2. Multiple frames could be rendered for a single vblank (redundant work) 3. Open loop rendering would inevitably have buffer swapping out of sync with vblanks and visual tearing would occur. This commit enables vsync on the glutin window. The rendering was all moved onto a separate thread from input/pty processing to support vsync. However, the rendering thread must be 100% synchronized with the updater thread. There's now a Mutex on the Term, and an atomic bool to ask the input/pty processing to yield to the renderer. One aspect of this feature that hasn't been worked out is how to limit the frame rate. Currently, it just free runs at the screen refresh rate. The initial attempt here included the input/pty processor holding a lock while waiting for input. This *almost* worked, but there was a (not uncommon) edge case where the terminal state was "dirty" but the renderer was not ready to draw. Instead of blocking on the refresh issue, it's being punted to after an MVP is released. The overhead of drawing at 60Hz was profiled to be ~5% CPU usage, and this is deemed acceptable for an MVP. |
||
|---|---|---|
| docs | ||
| font | ||
| res | ||
| src | ||
| .gitignore | ||
| .travis.yml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| LICENSE-APACHE | ||
| TASKS.md | ||
| build.rs | ||