VSCode终端不支持WebGL渲染引擎，仅提供dom和canvas两种可配置模式；xterm.js虽有WebGLRenderer但未被VSCode暴露，因终端字符渲染中WebGL开销过大、内存占用高且兼容性不如Canvas，实际场景中Canvas已足够平衡性能与稳定性。
VSCode 终端不支持 WebGL 渲染引擎。 它只提供 dom 和 canvas 两种渲染模式，webgl 不在可选值范围内，强行配置会静默失效或回退到默认值。
为什么 VSCode 终端没有 WebGL 选项
xterm.js 是 VSCode 终端的底层实现，它确实提供了 WebGLRenderer（位于 src/renderer/webgl.ts），但 VSCode 团队从未将其暴露为用户可配置项。原因很实际：
- 终端本质是字符栅格化任务，WebGL 的矩阵变换、着色器编译、纹理上传等开销远超收益
- WebGL 渲染器需维护完整 GPU 纹理缓存 + 字符 atlas + 多层合成逻辑，对内存和初始化时间不友好
- VSCode 的终端场景更关注输入响应、滚动流畅性和兼容性（比如 Windows 远程桌面、国产信创环境），Canvas 已足够平衡
Canvas vs DOM：这才是你该对比的真实选项
VSCode 中真正起作用的只有这两个渲染路径，它们的差异直接决定你打开日志文件或运行 docker logs -f 时的体验：
-
canvas模式下，整行文本被光栅化为位图，editor.cursorBlinking由 JS 定时器控制，不依赖系统光标设置 -
dom模式下，每个字符是独立<span></span>元素，支持 subpixel 渲染、CSS 动画、精确光标定位，但 10MB 文件可能生成数百万个 DOM 节点 - 远程开发（SSH/WSL）中，DOM 渲染会显著增加 WebSocket 数据量；Canvas 则只传输绘制指令和少量元数据
- macOS 上 Canvas 可能触发 CoreAnimation bug 导致滚动掉帧；Windows 远程桌面中 Canvas 常有光标偏移，DOM 可绕过
如何验证当前终端用的是哪种渲染器
不能靠设置项猜测，得看真实行为：
- 打开开发者工具（
Ctrl+Shift+P→Developer: Toggle Developer Tools），切换到 Elements 面板 - 展开
#terminal-container，如果子节点是大量<div class="xterm-rows"> + 内嵌 <code><span></span>，说明是dom渲染 - 如果只看到一个
<canvas></canvas>元素，且其width/height匹配终端尺寸，那就是canvas渲染 - 检查设置：运行
Developer: Open Settings (JSON)，确认"terminal.integrated.rendererType"值为"canvas"或"dom"—— 注意不是editor.renderingMode，那是编辑器的
WebGL 在终端场景里目前仍是理论可行、工程弃用的状态。真要压榨性能，优先调 terminal.integrated.gpuAcceleration（仅影响部分动画）、关掉不必要的装饰（如 terminal.integrated.enableMultiLinePasteWarning），比纠结不存在的 WebGL 更实在。
