Skip to content

Retain recycled swapchain surfaces#355

Open
hyperb1iss wants to merge 1 commit intoservo:mainfrom
hyperb1iss:upstream/recycle-swapchain-surfaces
Open

Retain recycled swapchain surfaces#355
hyperb1iss wants to merge 1 commit intoservo:mainfrom
hyperb1iss:upstream/recycle-swapchain-surfaces

Conversation

@hyperb1iss
Copy link
Copy Markdown

@hyperb1iss hyperb1iss commented May 6, 2026

Hi! My app is using Servo embedded and rendering high perf graphics into an offscreen canvas, and I noticed WebGL users were quickly eating large amounts of RAM until the process crashed. The app does not have this issue at all on Windows or Linux, only MacOS shows it. I traced it back to this code with Codex (gpt-5.5 xhigh), and with this change everything works perfect across all 3 platforms.

Summary

Keep recycled same-size swapchain surfaces in the pool across swaps instead of destroying all leftovers every frame.

Why

SwapChainData::swap_buffers already reuses one matching recycled surface as the next back buffer, but then drains and destroys every other recycled surface at the end of each swap. For high-frequency WebGL producers, this creates continuous surface create/destroy churn even when dimensions are stable. On macOS, where these surfaces are IOSurface/CGL-backed, that churn can show up as rapidly growing graphics footprint in long-running embedders.

The swapchain already owns these recycled surfaces and destroys them on destroy; this change also clears them on resize, where stale dimensions should be discarded.

Verification

  • cargo check --features chains
  • Validated in Hypercolor Servo/WebGL embedder at 60 FPS: IOAccelerator graphics memory stays stable instead of growing multiple GB over minutes.

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