Rendering.Gl.PlatformSupport
public static class Rendering.Gl.PlatformSupportThe guard rail around the GL entry points that are fatal under WebAssembly.
Emscripten publishes those symbols, so GetProcAddress hands back a real, non-null address — and calling one terminates the runtime. There is no exception to catch, no GL error to check and no console message; the page simply stops. Nine were found by calling the whole engine-relevant ES surface one entry point at a time, and the fault is the browser backend rather than any binding library, so no amount of care at the call site makes them safe.
The response is therefore not "handle the failure" but "never make the call". Code asks PlatformSupport.Allows first; everywhere but the browser the answer is yes and the feature behaves as written. In the browser the answer is no, the renderer takes its documented fallback, and — when warnings are on — the developer gets an IDE-style diagnostic naming the feature, what it costs and what to do instead. Silent degradation is the outcome worth avoiding: it is how you ship a browser build that looks subtly worse and never find out.
Two of the nine were never the browser's fault, and are no longer refused. They were catalogued when the demo was assembled with dotnet build, and a built WebAssembly application is not a published one: the native relink that WasmBuildNative asks for happens on publish, and it is what generates the interop trampolines for the signatures an application actually calls. Without it the address resolves, the trampoline behind it does not exist, and the call ends the process — which is exactly what was seen and written down. Publish the same source and both work.
Verified rather than assumed, on one source tree published four ways — interpreted and ahead-of-time compiled, each with the calls made and refused. All four run; the two features are present and correct wherever the calls are made, at the same frame rate. The acceptance test the depth-bias feature already had — a coplanar grid, biased on one panel and not the other — passes in the browser now, which is the evidence that the call has an effect rather than merely failing to kill the page. Limitation.Repaired marks the two. The rest fail for reasons publishing cannot touch, and stay refused.
Properties
| Member | Description |
|---|---|
| Refuses the repaired entry points as well, restoring the behaviour every release before this one had in the browser. Here because the failure it guards against is not survivable — no exception, no GL error, the page simply stops — so anyone who meets it needs a way out that is not "wait for the next release". Set it before the first frame is drawn. Nothing in this library sets it, and if you find you need it, that is worth reporting: it would mean a configuration where publishing does not generate the trampolines, which is a thing the documentation currently says cannot happen. |
| True when this process is WebAssembly in a browser, where the fatal entry points live. |
| Features skipped so far. Safe to read from any thread. |
| One line about the guarded entry points, for a log. About entry points, not about the picture. This used to be what a diagnostics panel showed, which was a mistake worth naming: of the eight features guarded here exactly one — anisotropic filtering — is ever asked for by this renderer, so "nothing skipped" was a claim about a list nobody was using, and under Metal it was a sentence about a graphics API that was not running. |
| Whether skipped features are announced. On by default in Debug builds, off in Release — the same convention as any other development-time diagnostic. Set it explicitly to inspect a published build. |