sublime text gpu加速需同时满足显卡驱动、系统图形栈和正确配置三者才生效；必须设"hardware_acceleration":"opengl"(win/linux)或"metal"(macos)，并启用"gpu_window_buffer":true，否则静默回退cpu渲染。
Sublime Text 的 GPU 加速不是“开了就流畅”，它只在满足显卡驱动、系统图形栈、配置三者全部就位时才真正生效；写错 hardware_acceleration 值（比如写成 true 或 "on"）会导致静默失效，你改了设置却没感觉，大概率卡在这一步。
hardware_acceleration 必须设为字符串枚举值
这个配置项只认三个合法值："opengl"（Windows/Linux）、"metal"（macOS）和 "none"。写 "hardware_acceleration": true、"on"、1 或留空，Sublime 都会直接忽略整行，不报错也不提示。
- Windows / Linux 用户：必须显式写
"hardware_acceleration": "opengl"—— 即使默认值是它，老旧集成显卡或远程桌面环境下也可能实际未启用 - macOS（尤其 Apple Silicon）：必须写
"hardware_acceleration": "metal"；删掉该行不会自动恢复，得手动补上 - 禁用 GPU 渲染：设为
"hardware_acceleration": "none"，回到类似 ST3 的纯 CPU 路径，适合排查是否真由 GPU 引起的撕裂或闪屏
gpu_window_buffer 必须配合后端启用
"gpu_window_buffer": true 不是独立开关，它只在 hardware_acceleration 指定了后端（"opengl" 或 "metal"）时才初始化 GPU 缓冲区。只开它、不开后端，GPU 加速基本无效。
- 高 DPI 屏幕滚动大文件（如 50MB+ 日志）、多标签频繁切换时出现窗口撕裂或延迟，才值得启用该组合
- Linux X11 环境下若仍失效，需确认桌面环境已启用 OpenGL 渲染（GNOME 在 Settings → About 页面可见 “Graphics Acceleration” 开关）
- Wayland 下通常线性加速更稳，但多数用户仍在 X11，此时还需确保安装完整 Mesa 库：
libgl1-mesa-glx和libegl1-mesa（Ubuntu/Debian）或mesa+lib32-mesa（Arch）
如何验证 GPU 渲染真生效了
Sublime 不提供 GUI 状态指示，只能靠控制台日志 + 行为交叉判断：
- 打开控制台（
Ctrl+`），输入sublime.log_commands(True) - 滚动一个真实大文件（比如 50MB 的日志或
node_modules里的长 JS 文件） - 观察输出：
OpenGL context created（Windows/Linux）或Metal context created（macOS）出现才算成功 - 若看到
Failed to create OpenGL context或software rendering fallback，说明驱动缺失、权限不足，或被 TeamViewer/OBS/Windows 远程桌面劫持图形栈
开了 GPU 还卡？问题大概率不在渲染层
GPU 加速只管界面绘制，对输入延迟、光标跳动、跳转卡顿几乎没用。即使 OpenGL context created 出现了，滚动仍卡顿，问题大概率出在：
-
"index_files": false必须加——否则百万行项目里光标移动、Ctrl+P搜索都会变慢 - 插件后台占用：特别是 Python 插件宿主（
plugin_host）在 ST4 中升级到 Python 3.8，部分旧插件未适配，会拖慢主线程 - 语法高亮或主题动画：Adaptive 主题、侧边栏过渡动画在低性能 GPU 上反而引入帧率波动，可临时切回
Default.sublime-theme并关掉"animation_enabled": false
真正影响滚动流畅度的，是 mmap 分块加载 + 视口感知渲染机制；GPU 只负责把那一小块画出来——画得快，不代表加载快、解析快、索引快。
