Skip to content

fix(browser): keep up with a busy page and stay sharp on HiDPI - #982

Merged
omartelo merged 2 commits into
mainfrom
fix/browser-frame-rate-hidpi
Oct 29, 2026
Merged

omartelo merged 2 commits into
mainfrom
fix/browser-frame-rate-hidpi

Conversation

@omartelo

Copy link
Copy Markdown
Collaborator

Why

On a page that animates or runs a lot of JavaScript, the session browser tab fell seconds behind the page, and the rest of the window waited with it. On a HiDPI screen the tab was also blurred.

Lag. The window decoded every screencast frame in turn on the /events loop. Chrome sends the next frame on the ack, and the ack goes out once the socket takes the frame, not once the window draws it, so nothing slowed Chrome down: frames queued in the 64-event buffer while each decode ran (5 ms on a light page, 15 ms on a busy one at 1280x720), and every other event queued behind them.

Blur. SetDeviceMetricsOverride with a scale of 2 changes the page's devicePixelRatio, but the screencast copies the headless browser's own surface, which stays at 1x. WithMaxWidth only scales down, so a 2x pane got 1280x720 frames for a 2560x1440 pane.

What

  • The window decodes off the /events loop, four frames at once (frameDecoders). While all four are busy a page keeps only its newest frame, and a frame carries a sequence number so an older one finishing last never replaces a newer one.
  • The headless browser launches with --force-device-scale-factor=1.5 and a pane's scale is capped there (frameScale). A 2x pane gets 1.5x frames; a 1x pane stays 1x. The browser in its own window keeps the monitor's scale.
  • docs/ceilings.md names the 1.5x cap, and no longer says frames come at the pace the window takes them.

Measurements (2026-10-29, Helium headless, 1280x720 pane)

Chrome sends one frame per frame the page paints; JPEG quality and a real GPU (RTX 3050 over Vulkan instead of SwiftShader) changed nothing.

Page JS per frame Screencast
CSS animation ~0 60 fps
6000 canvas particles + 1500 moving DOM nodes 7 ms 58-60 fps
same + 4 ms of app logic 11 ms 49 fps

Forced device scale on that busy page: 45 fps drawn at 1x, 33 at 1.5x, 28 at 2x (forced to 2). Forcing 3 cost frames even at 1x, which is why the forced scale is the cap and not something higher.

Test plan

  • TestBrowserFramesDecodeTwoAtOnce, TestBrowserFrameSurplusDecodesOnlyTheNewest, TestOlderBrowserFrameDecodedLastKeepsTheNewer: 300 runs with -race; the first fails with frameDecoders = 1
  • TestChromeScreencastDrawsAHiDPIPaneAtTheFrameScale (live Chrome): failed with a 400x300 frame for a 400x300 pane at 2x before the fix, gets 600x450 after
  • Backend: gofmt -l ., go vet ./..., go test ./...
  • native/: gofmt -l ., go vet ./..., go test ./...

The window decoded every screencast frame in turn on the /events loop.
A busy page sends frames faster than one decode takes, so they queued
for seconds and every other event waited behind them. Four decoders now
take frames at once, a page keeps only its newest frame while all four
are busy, and an older frame finishing last never replaces a newer one.
An emulated device scale changes the page's devicePixelRatio but not the
surface the screencast copies, so a 2x pane got 1x frames, blurred. The
headless browser now launches with its scale forced to 1.5 and a pane's
scale is capped there: 2x halved a busy page's frame rate.
@omartelo
omartelo merged commit ee8e2b0 into main Oct 29, 2026
7 checks passed
@omartelo
omartelo deleted the fix/browser-frame-rate-hidpi branch October 29, 2026 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant