mirror of
https://github.com/wez/wezterm.git
synced 2024-10-27 16:19:25 +03:00
e188406dfc
This commit decomposes the main get_semantic_zones method into two parts: * A per-line portion, where the line ranges are cached (invalidated on change) * The overall screen portion, where the line ranges are merged This changes the overall complexity of computing zones from O(width * scrollback-height) To an incremental: O((width * number of changed lines since last query) + scrollback-height) You can see some samples of elapsed time below; those show the times for running both the old and the new implementation on the same data. The number of lines/zones in the scrollback increases with each call and you can see that the new implementation is a bit faster anyway at low volumes but is significantly faster as the number of lines/zones increases, because the amount of work is reduced. ``` get_semantic_zones: 71.708µs get_semantic_zones_new: 59.041µs get_semantic_zones: 71.166µs get_semantic_zones_new: 9.166µs get_semantic_zones: 44.291µs get_semantic_zones_new: 4.208µs get_semantic_zones: 69.791µs get_semantic_zones_new: 10.291µs get_semantic_zones: 59.375µs get_semantic_zones_new: 7.958µs get_semantic_zones: 52.5µs get_semantic_zones_new: 4.5µs get_semantic_zones: 91.791µs get_semantic_zones_new: 20.916µs get_semantic_zones: 229.916µs get_semantic_zones_new: 109.208µs get_semantic_zones: 224.125µs get_semantic_zones_new: 15.208µs get_semantic_zones: 291.791µs get_semantic_zones_new: 11.833µs get_semantic_zones: 238.875µs get_semantic_zones_new: 12.625µs get_semantic_zones: 468.458µs get_semantic_zones_new: 126.583µs get_semantic_zones: 460.5µs get_semantic_zones_new: 25.666µs get_semantic_zones: 358.291µs get_semantic_zones_new: 19.541µs get_semantic_zones: 436.833µs get_semantic_zones_new: 17.875µs get_semantic_zones: 313.166µs get_semantic_zones_new: 15.25µs get_semantic_zones: 333.958µs get_semantic_zones_new: 16.541µs get_semantic_zones: 364.666µs get_semantic_zones_new: 14.041µs ``` |
||
|---|---|---|
| .. | ||
| data | ||
| examples | ||
| src | ||
| Cargo.toml | ||
| LICENSE.md | ||
| README.md | ||
Terminal Wizardry
This is a rust crate that provides a number of support functions for applications interested in either displaying data to a terminal or in building a terminal emulator.
It is currently in active development and subject to fairly wild sweeping changes.
Included functionality:
Surfacemodels a terminal display and its componentCells- Terminal attributes are aware of modern features such as True Color, Hyperlinks and will also support sixel and iterm style terminal graphics display.
Surfaces include a log ofChanges and an API for consuming and applying deltas. This is a powerful building block for synchronizing screen instances.- Escape sequence parser decodes inscrutable escape sequences and gives them semantic meaning, making the code that uses them clearer. The decoded escapes can be re-encoded, allowing applications to start with the semantic meaning and emit the appropriate escape sequence without embedding obscure binary bytes.
Capabilitiesallows probing for terminal capabilities that may not be included in the system terminfo database, and overriding them in an embedding application.Terminaltrait provides an abstraction over unix style ttys and Windows style console APIs.Changes fromSurfacecan be rendered toTerminals.Terminals allow decoding mouse and keyboard inputs in both blocking or non-blocking mode.Widgettrait allows composition of UI elements at a higher level.LineEditorimplements shell-like line editing functionality.
Windows Support
Termwiz understands how to work with both the legacy console APIs and the new PTY and virtual terminal features available in Windows 10, allowing for true color terminal applications on Windows 10.