全屏后输入延迟、滚动掉帧本质是macos windowserver与sublime opengl渲染层资源争夺，需同步修改系统scrollwheel.scaling值（1.8）及sublime配置：overlay_scroll_bars禁用、always_show_scroll_bar启用、smooth_scroll与scroll_speed设为2.3，并强制hardware_acceleration为"opengl"。
全屏后输入延迟、滚动掉帧，本质是渲染路径冲突
Mac 上 Sublime Text 3 全屏卡顿不是编辑器本身 bug，而是 macOS 的窗口管理器（WindowServer）与 Sublime 的 OpenGL 渲染层在全屏模式下争夺合成资源，尤其在 M 系列芯片 + macOS 14+ 环境中，overlay_scroll_bars 和系统级滚动缩放参数会直接导致帧率崩塌。你点不动、拖不动、输不进，不是 CPU 满了，是 GPU 渲染管线被反复打断。
必须同步改系统设置和 Sublime 配置
只调 Sublime 设置或只改系统偏好都不行，缺一不可：
- 终端执行：
defaults write -g com.apple.scrollwheel.scaling -float 1.8，然后killall cfprefsd刷新系统偏好（仅重启 Sublime 无效） - Sublime 用户设置里加：
"overlay_scroll_bars": "disabled"和"always_show_scroll_bar": true - 加上：
"smooth_scroll": true和"scroll_speed": 2.3，避免默认值触发低帧率 fallback - 强制启用 OpenGL：
"hardware_acceleration": "opengl"—— macOS 可能默认用 Metal 或软件渲染，但 Sublime 的 minimap 和滚动动画严重依赖 OpenGL 上下文
全屏卡顿常被误判为插件问题
现象：进入全屏后几秒内开始卡，退出全屏立刻恢复；安全模式（Cmd 启动）下依然卡 —— 这说明不是插件或 index_files 导致的。真正高危组合是：
- 启用了
highlight_line或draw_white_space，全屏时重绘区域扩大数倍，放大渲染压力 - 侧边栏开着大项目（含
node_modules），即使index_files关了，全屏焦点切换仍会触发部分 UI 重绑定 - 用了第三方鼠标驱动（如 Logitech Options、Razer Synapse），它们会劫持滚动事件并干扰 Sublime 的 scroll handler
验证方法：全屏状态下打开控制台（control + `），输入 sublime.log_commands(True)，观察是否大量输出 on_activated 或 on_modified —— 如果没有，就基本排除插件逻辑阻塞。
别忽略窗口层级和显示器配置
M 系列 Mac 多显示器环境下，Sublime 全屏卡顿往往只发生在外接显示器（尤其是 HDMI/DisplayPort 非原生分辨率），因为 macOS 会为不同显示器分配不同渲染上下文，而 Sublime 没做适配：
- 尝试将 Sublime 拖到主屏再全屏，看是否改善
- 关闭“镜像显示”，或在外接屏上设为“默认缩放”而非“缩放”模式
- 禁用“自动调整亮度”和“True Tone”，这两个功能会在全屏时动态调节 GPU 输出，干扰 OpenGL 帧同步
最隐蔽的坑：如果你用的是 macOS 的“跨显示器全屏”（即全屏窗口横跨两个屏），Sublime 不支持该模式，会退化成窗口化渲染，但 UI 线程仍按全屏逻辑跑，结果就是光标响应慢半拍、快捷键延迟、甚至 command + tab 切换卡住。
