proposal-ecmascript-sharedmem
proposal-ecmascript-sharedmem copied to clipboard
tc39
Web GL API safelisting: Web GL 1.0 vs. 2.0
My understanding is that several browsers have implemented or are implementing Web GL 2.0. Additionally, I would have to assume that the editors do not accept changes to Web GL 1.0, only 2.0. (Is that true?)
Should https://tc39.github.io/ecmascript_sharedmem/dom_shmem.html#webgl be updated to target Web GL 2.0?
Yeah, probably. See https://github.com/tc39/ecmascript_sharedmem/issues/38#issuecomment-259731137 et seq for an older discussion. Basically this is stalled on making progress on the WebIDL side, where (last time I looked) there was disagreement between you, Anne, and Boris about how to frame the types.
We're all good now :). The plan is to get https://github.com/heycam/webidl/pull/286 merged and then we can define [AllowShared] to apply to the binary data types, and add [AllowShared] as appropriate.
So we're getting [AllowShared] ready in https://github.com/heycam/webidl/pull/353. But it's becoming more and more pressing to have some sort of comprehensive list of APIs that will use it, so that browsers can all be on the same page and we can write tests. /cc @binji
I'll work on a PR for the Web GL spec.
I landed this a couple of weeks ago in Chrome, enabling WebGL 1 and 2 APIs. The tests I added were just surface-level -- ensuring that you could pass a SharedArrayBuffer view through to the API without it throwing an exception. Conveniently, all WebGL APIs set an error instead, so it wasn't necessary to have valid data passed to the functions (just valid types).
What does it mean to set an error? Shouldn't we also have tests that demonstrate it actually works?
As I noted over in the WebGL issue, https://github.com/KhronosGroup/WebGL/pull/2387, aggressively (for the lack of a better word) annotating everything with [AllowShared] is maybe a little risky. What we had with the WebGL 1.0 changes was the minimum @juj was able to get away with needing for asm.js/wasm.
(I have zero WebGL chops so it's hard for me to say what is (a) desirable or (b) risky. I just want to advocate a go-slow approach backed by implementation experience in each case.)