From be6fb8a3f8f549ca4691641259abd1b1e29ef6c2 Mon Sep 17 00:00:00 2001 From: Uyanide Date: Thu, 12 Feb 2026 23:18:25 +0100 Subject: [PATCH] more about terminals --- memo/terminals.md | 51 +++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 45 insertions(+), 6 deletions(-) diff --git a/memo/terminals.md b/memo/terminals.md index 15e02ae..6300460 100644 --- a/memo/terminals.md +++ b/memo/terminals.md @@ -78,12 +78,12 @@ Shell 是运行在 TTY Slave 端的命令行解释器, 负责: 控制序列是一种特殊的字节序列, 基于不同协议, 用于在终端模拟器中实现各种功能, 如: -- `CSI` (Control Sequence Introducer): 以 `\033[` 开头 +- **CSI** (Control Sequence Introducer): 以 `\033[` 开头 - 光标移动: `\033[;H` 或 `\033[;f` - 清屏: `\033[2J` - 颜色设置: `\033[38;2;;;m` (前景色), `\033[48;2;;;m` (背景色) -- `OSC` (Operating System Command): 以 `\033]` 开头 +- **OSC** (Operating System Command): 以 `\033]` 开头 - 设置窗口标题: `\033]0;title\a` - 设置剪贴板内容: `\033]52;c;data\a` @@ -101,7 +101,7 @@ Shell 是运行在 TTY Slave 端的命令行解释器, 负责: ### 各终端支持情况 -不完全统计, 只列举我知道和确实使用过的. +不完全统计, 只列举我知道并且确实使用过的. | Terminal | KGP | Sixel | ITerm | | ------------- | --- | ----- | ----- | @@ -115,6 +115,7 @@ Shell 是运行在 TTY Slave 端的命令行解释器, 负责: | Tabby | ❌ | ✅ | ❌ | | Warp | ✅ | ❌ | ❌ | | WezTerm | ✅ | ✅ | ✅ | +| Windows Term. | ❌ | ✅ | ❌ | ### 使用方法 @@ -130,7 +131,9 @@ Shell 是运行在 TTY Slave 端的命令行解释器, 负责: wezterm imgcat /path/to/image ``` - 将会使用 ITerm 图形协议形式图片. 以上两个指令在其他支持相同协议的终端模拟器同样可用. + 将会使用 ITerm2 图片协议形式图片. + + 以上两个指令在其他支持相同协议的终端模拟器同样可用. - 另一个很好用的通用程序是 [chafa](https://github.com/hpjansson/chafa). 除了自动检测并使用以上三种协议显示图片外, 它还支持以 `symbols` 格式使用 [ANSI 颜色转义序列](https://en.wikipedia.org/wiki/ANSI_escape_code)显示图片的大致样貌, 这在不支持以上任何一种协议的终端模拟器(如 Alacritty)上很好用. @@ -172,7 +175,7 @@ Sixel 支持情况可以用 `DA1` 查询, 即 `\033[c`. 如响应中分号分隔 #### ITerm -ITerm2 图片协议本质为 `OSC 1337` 控制序列的 `FILE` 特性. ITerm2 文档虽然提供了[检测方法](https://iterm2.com/feature-reporting/), 但一番测试后发现在我认知范围内的支持 ITerm2 图片协议的终端上均无法得到有效相应. +ITerm2 图片协议本质为 `OSC 1337` 控制序列的 `FILE` 特性. ITerm2 文档虽然提供了[检测方法](https://iterm2.com/feature-reporting/), 但一番测试后发现在我认知范围内的支持 ITerm2 图片协议的终端模拟器上均无法得到有效响应. 但还有其他方法可以实现查询目的. 虽然无法直接查询 `FILE` 特性的支持情况, 但可以通过执行 `OSC 1337` 控制序列中其他副作用和开销较小的查询来间接获知是否支持该控制序列, 进而获知是否支持通过该协议显示图片. 一种常见的方法是查询 `ReportCellSize`, 具体控制序列为 `\033]1337;ReportCellSize\a`. 如果返回了以 `\033]1337;ReportCellSize=` 为前缀的响应, 则可视为通过. 虽然看起来并不怎么健壮, 但根据我自己的测试结果误判可能性很小, 已经足够使用了. @@ -278,7 +281,7 @@ bash <(curl -fsSL https://tgp.uyani.de/query) bash <(curl -fsSL https://tgp.uyani.de/kitty) ``` -将会尝试用 KGP 显示一张测试图片, 如果显示成功则说明支持 KGP, 反之则不支持. +将会尝试用 KGP 显示一张测试图片, 如果显示成功则说明支持 KGP, 反之则(大概率)不支持. > [!TIP] > @@ -322,6 +325,42 @@ KGP 既支持直接传输 PNG 二进制数据, 也支持传输 24bit 与 32bit | WezTerm | 970.4 | 980.2 | 962.0 | | Foot | - | 719.6 | - | +可以大致得出以下结论: + +- Sixel 确实存在性能优势, 但上下限差距明显. + + 因为统一预处理流程, 此处可以排除因量化/抖动等步骤导致的性能差异. 且 Sixel 为 7bit 传输, 省去了 Base64 编解码的开销. 但解析器编写难度大, 流程较为复杂, 因此不同终端模拟器的实现差异较大, 且在大图场景下性能优势并不明显. + +- KGP 和 ITerm 的性能表现则更受终端模拟器具体实现的影响. 不同终端在面对两种场景时可能有相反的性能表现. + - 对于 KGP, 测试中统一转换为 32bit 像素数据传输. + - 对于 ITerm, 测试中统一转换为 32bit 像素数据后加上 TIFF 头部传输. + + 这能够解释为什么 KGP 和 ITerm 的性能差异在测试中不明显, 因为二者对于同一个终端模拟器来说有相似的解码与渲染开销. + +- 小图连续输出场景, Ghostty 和 Foot 的表现优于其他终端模拟器. + + 主要考察协议握手开销与 IPC 效率. + +- 大图连续输出场景, Kitty 和 WezTerm 的表现优于其他终端模拟器. + + 主要考察数据传输, 解码与渲染效率. + +- Foot 无 GPU 加速, 但在 Sixel 协议下性能表现优于其他终端模拟器. + + 这再次证明 GPU 加速并非终端模拟器性能的决定性因素. + +如果从吞吐与延迟的角度分析: + +- KGP 与 ITerm + - Kitty 与 WezTerm 的吞吐量较高, 延迟同样较高. + + - Ghostty 与 Konsole 的吞吐量较低, 延迟同样较低. + +- Sixel + - Konsole 与 Foot 的吞吐量较高, 延迟却较低. + + - WezTerm 的吞吐量中等, 延迟较高. + ## 默认 Shell > 虽然这和终端模拟器关系不大, 但姑且放这里一起说说.