fix(cli): enable DEC synchronized output on Warp to reduce redraw flicker - #8832
fix(cli): enable DEC synchronized output on Warp to reduce redraw flicker#8832chiga0 wants to merge 1 commit into
Conversation
|
Thanks for the PR! Template looks good ✓ Problem: Observed, not theoretical. The flicker half of #8557 was investigated directly on Warp (probe evidence recorded in the issue thread): a DECRQM 2026 probe in Warp answers Direction: Aligned. DEC 2026 synchronized output is already qwen-code's established flicker mitigation (WezTerm and iTerm sit on this same allowlist), and the area is actively maintained in the same spirit elsewhere — Claude Code's changelog has several entries fixing rendering flicker exactly this way (enabling synchronized output for tmux 3.4+, and for JetBrains IDE terminals). Size: Not applicable — Approach: The scope is exactly right. One allowlist entry, one parameterized test row, one why-comment; the existing Risk: No elevated risk signals — none of the changed files match the high-risk paths from the revert-history analysis. Non-Warp terminals are untouched by construction: allowlist addition only, exact-match Moving on to code review. 🔍 中文说明感谢贡献！ 模板完整 ✓ 问题：真实观测到的问题，不是理论加固。#8557 的闪烁半边已在 Warp 上直接调查过（issue 线程里记录了探针证据）：Warp 中 DECRQM 2026 探针返回 方向：对齐。DEC 2026 synchronized output 本来就是 qwen-code 既有的闪烁缓解手段（WezTerm、iTerm 已在同一白名单），这个方向在别处也在持续维护——Claude Code 的 changelog 里就有多条用同样方式（为 tmux 3.4+、JetBrains IDE 终端启用 synchronized output）修复渲染闪烁的记录。 规模：不适用—— 方案：范围恰好。一个白名单条目、一行参数化测试、一条 why 注释；既有逃生门 风险：无升级风险信号——改动文件均未命中 revert 历史分析出的高风险路径。非 Warp 终端按构造不受影响：仅白名单新增、 进入代码审查 🔍 — Qwen Code · qwen3.8-max Reviewed at |
Code reviewIndependent take before reading the diff: "flicker on Warp because frame updates erase-then-rewrite; DEC 2026 available per probe" → add Warp's Findings: no blockers, no convention violations.
Testing evidence — the PR's own CI, read via API⛔ Per the unattended-CI rules, no PR code was built or executed here; this section quotes the check results GitHub recorded for the reviewed commit. Classification of the one red check — stale-branch CI infrastructure failure, not caused by this PR's code: the ubuntu test job died in job setup, before any test ran, with
Sandboxed lanes: once the branch is rebased and CI can actually run, the unit suite pins the mechanism itself (drop the allowlist line and the new test row fails). Sandboxed verification would settle the remaining regression half: Real-scenario testing: N/A — unattended CI run; live-behavior signal comes from the lanes above, not from anything executed here. Not verified: any Warp visual behavior (no Warp in CI); the unit suite on this head (job failed in setup before tests ran). 中文说明代码审查读 diff 之前的独立判断：既然"Warp 上帧更新先擦后写导致闪烁、探针证实 DEC 2026 可用"，做法就是在 结论：无阻塞项，无规范违规。
测试证据——经 API 读取的 PR 自身 CI⛔ 按无人值守 CI 规则，此处未构建或执行任何 PR 代码；本节引用 GitHub 对被审 commit 记录的检查结果。 唯一红色检查的定性——分支过旧导致的 CI 基础设施失败，与本 PR 代码无关：ubuntu 测试 job 在任何测试运行之前就死于 job setup，报错 沙箱验证通道：分支 rebase、CI 能真正跑起来之后，单测即可钉住机制本身（删掉白名单那一行，新增测试就会失败）。 真实场景测试：不适用——无人值守 CI 运行；实行为信号来自上述通道，此处未执行任何代码。 未验证：Warp 上的任何视觉行为（CI 无 Warp）；该 head 上的单测套件（job 在测试运行前的 setup 阶段失败）。 — Qwen Code · qwen3.8-max Reviewed at |
|
Confidence: 4/5 — clean, minimal, evidence-backed change; docking the fifth because CI has never actually run on this head (stale branch) and the Warp visual confirmation is still owed. This one is easy to say yes to. The author didn't guess: the #8557 thread shows a probe-based investigation on a real Warp install (DECRQM 2026 → status 2), and the change itself is the smallest thing that could work — one allowlist entry mirroring the existing WezTerm/iTerm ones, one test row, one honest why-comment, and the scope stated truthfully (flicker half only; the resize-duplication half is documented as Warp platform behavior and deliberately left out). My independent proposal for this problem was identical to the diff, which is about as good as it gets for a fix like this. The only thing standing between this PR and merge is mechanical, not substantive: the branch sits 132 commits behind The approval below is pinned to the reviewed commit; pushing the rebase dismisses it by design, and triage will take a fresh look at the green head. Approving while CI is red on this head is safe exactly because of that pinning — branch protection still requires green checks to merge. 中文说明这个 PR 很容易让人点头。作者不是在猜：#8557 线程里记录了在真实 Warp 环境下的探针调查（DECRQM 2026 → status 2），而改动本身就是能起作用的最小形态——一个镜像既有 WezTerm/iTerm 条目的白名单项、一行测试、一条诚实的 why 注释，范围也说得实话实说（只处理闪烁半边；resize 重复的半边已记录为 Warp 平台行为、有意排除在外）。我对这个问题的独立方案与这个 diff 完全一致——对这类修复来说，这已经是最好的结果。 横在 PR 与合并之间的唯一问题机械而非实质：分支落后 下面的 approve 钉在被审 commit 上；推送 rebase 会按设计将其作废，triage 会对变绿的 head 重新审一遍。之所以敢在 CI 红着的时候 approve，正是因为这种钉定——分支保护仍然要求绿色检查通过才能合并。 — Qwen Code · qwen3.8-max Reviewed at |
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
中文说明
— qwen3.8-max via Qwen Code /review (v0.21.8)
…cker Warp answers the DECRQM 2026 probe with status 2 (recognized, reset), so synchronized updates are available there. Without them Warp renders ink's erase-then-rewrite frame pattern as visible flicker (issue #8557). Add WarpTerminal to the synchronized-output allowlist; the existing QWEN_CODE_DISABLE_SYNCHRONIZED_OUTPUT escape hatch covers regressions.
b6eac11 to
0ba19b4
Compare
|
Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. 中文请勿对活跃的 PR 执行 rebase 或 force-push，因为这会使已有的评审评论失效。另外，供日后参考：作为集成流程的一部分，机器人始终会自动将所有改动压缩（squash）为单个提交。 |
|
Consolidated into #8831 per maintainer preference (single PR for the resize/wake repaint fix + DEC 2026 allowlist). The branch is merged into fix/wake-repaint-vp-clear. |
2 participants
What this PR does
Adds Warp and Ghostty to the allowlist of terminals that receive DEC 2026 synchronized updates around each frame write, so both get the same atomic erase-then-rewrite treatment as WezTerm and iTerm.
Why it's needed
The renderer's frame update erases the previous frame and rewrites it; terminals that paint intermediate states show that as flicker, most visible during resize drags (issue #8557). Warp answers a DECRQM 2026 probe with status 2 (mode recognized, currently reset) and Ghostty implements synchronized output natively, but both were outside the allowlist. With updates enabled, each erase+draw pair applies atomically and the drag flicker collapses to clean relayouts. The existing
QWEN_CODE_DISABLE_SYNCHRONIZED_OUTPUT=1escape hatch covers any regression.Reviewer Test Plan
How to verify
In Warp or Ghostty, run
npm run dev, send a prompt and watch streaming, then resize the window: expected frame updates without erase/rewrite tearing; withQWEN_CODE_DISABLE_SYNCHRONIZED_OUTPUT=1the previous flicker returns. A DECRQM probe (printf '\e[?2026$p'in Warp) returnsCSI ? 2026 ; 2 $ y. Non-allowlisted terminals are unaffected.Evidence (Before & After)
Capability proven by the DECRQM probe (Warp) and Ghostty's documented DEC 2026 support; author-observed on Ghostty: drag flicker reduced to atomic relayouts when combined with the repaint fix in the companion PR.
Tested on
Environment (optional)
npm run devin Warp and Ghostty on macOS.Risk & Scope
Linked Issues
References #8557. Does not close it.
中文说明
这个 PR 做了什么
把 Warp 与 Ghostty 加入 DEC 2026 synchronized updates 白名单，与 WezTerm/iTerm 同等获得原子化帧更新。
为什么需要
渲染器每帧先擦后写；会把中间态画出来的终端表现为闪烁，resize 拖拽时最明显（#8557）。Warp 的 DECRQM 2026 探针返回 status 2，Ghostty 原生支持 2026，但二者此前不在白名单。启用后擦+写原子应用，拖拽闪烁收敛为干净的重排。逃生门
QWEN_CODE_DISABLE_SYNCHRONIZED_OUTPUT=1覆盖回归。评审测试计划
Warp/Ghostty 中
npm run dev，流式输出并拖拽：期望无擦/写撕裂；设逃生门后旧闪烁复现。非白名单终端不受影响。风险与范围
关联 issue
参考 #8557，不关闭。