fix(windows): stop presents outrunning the display, cap Skia's cache, fix deleteShader

[triniwiz]

Three Windows fixes found while building a demo app on 3.0.0-alpha.15 (2D, WebGL, WebGPU, three.js, PixiJS).

Don't present faster than the display

Swapchains are created with DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT, which stops Present from throttling, but nothing waited on the object. requestAnimationFrame runs at ~66–70 fps here against a 59 Hz display, so frames and the GPU work each holds queued without bound: an opaque canvas running a busy 2D demo grew by ~100 MB/s, reached 21 GB and went black.

CompositionSwapChain::acquire_frame() checks the waitable without blocking. When the display hasn't taken the queued frames, the 2D (present_d3d) and WebGL (egl.rs) presents are skipped. The drawing stays in the canvas's own surface or texture. The frame scheduler keeps that context dirty on a retry list and flushes it again from requestAnimationFrame, so nothing blocks the UI thread and no frame rate is capped. After 250 ms of skipped presents, one goes through anyway, so a canvas can't stop updating for good.

No JS or C ABI changes. The skip reaches the scheduler through a thread-local in dxgi.rs, since flushes are synchronous on one thread.

A blocking wait was tried first. It capped fps at the display rate and made an intermittent startup stall of the XAML dispatcher much more likely (3 of 4 launches, against ~1 in 8 without the wait).

Cap and purge the shared Skia resource cache

All D3D canvases on a thread share one DirectContext, which kept Skia's default 256 MB resource cache and never purged it. Its buffers live in D3D12 upload heaps, which grew to 480 MB (the allocator's 32 + 64 + 128 + 256 MB blocks). The budget is now 64 MB, and resources unused for 5 s are freed, checked at most once a second while presenting.

deleteShader takes a WebGLShader

The binding declared a WebGLRenderbuffer, so every deleteShader(shader) threw Value is not an instance of class WebGLRenderbuffer. three.js and PixiJS both call it after linking, so neither started.

Testing

Windows 11, x64, Intel Iris Xe, 59 Hz, release-napi build of this branch in the app:

	Before	After
Busy 2D canvas, 40 s	+~100 MB/s	flat at ~700 MB, 67–70 fps
Demo home screen (several canvases)	~770 MB	~385 MB, flat over 3 min
Launches with a demo starting immediately	–	9 of 9 without the dispatcher stall
three.js / PixiJS demos	throw on start	start and run

Still open, not addressed here: creating and destroying three.js and PixiJS canvases retains roughly 15 MB per cycle. 2D, WebGL shader and WebGPU canvases return to baseline.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: f13892ff-4591-4307-9969-b242333fb171

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}