-
Notifications
You must be signed in to change notification settings - Fork 32
Web GL API safelisting: Web GL 1.0 vs. 2.0 #168
Comments
Yeah, probably. See #38 (comment) 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 whatwg/webidl#286 merged and then we can define |
Makes me happy :) |
So we're getting [AllowShared] ready in whatwg/webidl#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, KhronosGroup/WebGL#2387, aggressively (for the lack of a better word) annotating everything with (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.) |
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?
The text was updated successfully, but these errors were encountered: