Sublime Text文本渲染不依赖Chromium，靠C++原生引擎直接调用系统绘图API（Windows用GDI/Direct2D、macOS用Core Graphics、Linux用Cairo+X11/Wayland），实现无Web栈的像素级绘制；同时通过mmap异步分块加载与视口感知渲染，仅处理可见区域内容，确保大文件滚动流畅。
Sublime Text 的文本渲染不走 Chromium，靠的是什么
它根本没用 Web 技术栈。Sublime Text 的核心渲染引擎是 C++ 编写的原生模块，直接调用操作系统级绘图 API（Windows 上是 GDI / Direct2D，macOS 是 Core Graphics，Linux 是 Cairo + X11 / Wayland）。这意味着没有 V8 引擎解析 JS、没有 Blink 渲染 HTML、也没有 Electron 那套多进程沙箱——所有像素都由编辑器自己一帧一帧画出来。
常见错误现象：有人误以为 Sublime 启动快是因为“插件少”，其实即使禁用全部插件，VS Code（Electron）启动仍比 Sublime 慢 2–3 秒，根源就在这一层。你可以用 ps aux | grep code 和 ps aux | grep sublime 对比进程数和内存驻留量，前者通常有 4–6 个子进程，后者只有 1 个主进程 + 若干插件子进程（且只在需要时 fork）。
为什么滚动大文件不卡：异步分块 + 内存映射
Sublime Text 不把整个文件 load 进内存，而是用 mmap() 将文件按页映射到虚拟地址空间，再配合 viewport-aware rendering：只解码并绘制当前可视区域前后几屏的内容，其余部分保持为 raw bytes，连语法高亮都不触发。
- 打开一个 500MB 的
big.log，底部状态栏显示 “Loading…” 时间通常 - 快速滚动时，未加载行会延迟渲染（你可能看到灰块或占位符），但不会阻塞 UI 线程——这是典型的异步分块策略
- 如果禁用
mmap（比如通过设置"enable_mmap": false），大文件打开速度反而变慢，内存峰值飙升，说明该机制默认启用且关键
GPU 加速开关实际影响哪些渲染路径
"gpu_window_buffer": true 并不是简单地“打开显卡”，它只在特定条件下生效：Windows 上启用 Direct2D 后端，macOS 上启用 Metal，Linux 上依赖 OpenGL 3.3+。老旧集成显卡（如 Intel HD Graphics 4000）反而可能因驱动 bug 导致文字模糊或闪烁，这时应设为 false。
容易踩的坑：
- 开启后若出现光标错位或选区渲染异常，先检查显卡驱动版本，再尝试关闭
gpu_window_buffer -
"hardware_acceleration": "enabled"是旧版配置项，ST4 已废弃，设了也无效 - MiniMap、Gutter Icons、Syntax Highlighting 这些组件是否 GPU 加速，取决于它们是否被纳入 window buffer 绘制流程——不是所有元素都受益
语法高亮不拖慢编辑，靠 syntect 的增量解析机制
Sublime Text 自 v3.2 起内置基于 Rust 的 syntect 库做语法解析，但它不做全量重解析。每次键入字符，只对当前行及上下 2 行重新 tokenize；括号匹配、作用域推导等操作也限制在局部 scope，避免 O(n²) 复杂度。
验证方式：
- 打开一个 10k 行 Python 文件，打开控制台（
Ctrl+`），输入sublime.log_commands(True) - 连续敲击
def，观察日志中on_modified触发频率——你会看到每敲一个字符只触发一次轻量级 re-tokenize，而非整文件重扫 - 如果某语言高亮明显卡顿（比如自定义
.sublime-syntax中存在无限回溯正则），问题一定出在语法定义本身，不是引擎
真正影响性能的从来不是“有没有高亮”，而是“怎么高亮”——syntect 的 state machine 设计让高亮变成可预测的常数时间操作，这才是老电脑上依然流畅的关键。
