Bug 250307 - "TypeError: Type error" when calling WebGL bufferData with typed array backed by growable SharedArrayBuffer
Summary: "TypeError: Type error" when calling WebGL bufferData with typed array backed...
Status: RESOLVED DUPLICATE of bug 249635
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGL (show other bugs)
Version: Safari Technology Preview
Hardware: Mac (Apple Silicon) macOS 13
: P2 Normal
Assignee: Yusuke Suzuki
URL:
Keywords: InRadar
Depends on: 248024
Blocks:
  Show dependency treegraph
 
Reported: 2023-01-08 21:01 PST by Ian Kettlewell
Modified: 2023-01-09 15:33 PST (History)
5 users (show)

See Also:


Attachments
Index.html file with the code to reproduce the issue (523 bytes, text/html)
2023-01-08 21:01 PST, Ian Kettlewell
no flags Details
server to run the file with (415 bytes, text/x-python-script)
2023-01-09 01:43 PST, Kimmo Kinnunen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Kettlewell 2023-01-08 21:01:07 PST
Created attachment 464415 [details]
Index.html file with the code to reproduce the issue

As title says. The following code errors in Safari Technical Preview 160:

```
 let gl =
            canvas.getContext('webgl2');


        const sab = new SharedArrayBuffer(1024, {
            maxByteLength: 2048 // This is important, without it the page runs fine
        });

        const data = new Uint8Array(sab, 0, 32);
        let buffer = gl.createBuffer();
        gl.bindBuffer(gl.ARRAY_BUFFER, buffer); // TypeError: Type error
        gl.bufferData(gl.ARRAY_BUFFER, data, gl.STATIC_DRAW);
```

I discovered this in a game jam entry I made (https://ianjk.com/ld52/) that I was testing in the Safari Technology Preview. For some reason the SharedArrayBuffer backing the WebAssembly binary is automatically made 'growable' in Safari Technology Preview 160. In Safari 16.2 that does not happen so both the attached example and my game jam entry run fine.

I'm not versed in where to file WebKit bugs so I've filed this under 'WebGL', but please reclassify if there's a more appropriate 'Component'. :)
Comment 1 Kimmo Kinnunen 2023-01-09 01:43:46 PST
Created attachment 464416 [details]
server to run the file with
Comment 2 Kimmo Kinnunen 2023-01-09 01:45:23 PST
Likely regressed with bug 248024

Yusuke, it appears intentional.
Is there anything WebGL code can do to opt into using the growable array buffers?
Comment 3 Radar WebKit Bug Importer 2023-01-09 01:45:34 PST
<rdar://problem/104022514>
Comment 4 Yusuke Suzuki 2023-01-09 06:00:18 PST
(In reply to Kimmo Kinnunen from comment #2)
> Likely regressed with bug 248024
> 
> Yusuke, it appears intentional.
> Is there anything WebGL code can do to opt into using the growable array
> buffers?

Growable SharedArrayBuffer / Resizable ArrayBuffer cannot be used for IDL saying ArrayBuffer without [[AllowResizable]] annotation. (This is explicitly specified for resizable array-buffer / growable shared-array-buffer).

https://webidl.spec.whatwg.org/#AllowResizable

"If the [AllowResizable] extended attribute and the [AllowShared] extended attribute both appear on one of the buffer source types, it creates a new IDL type that allows the buffer source type to be additionally backed by an ECMAScript SharedArrayBuffer that is growable."

Thus, given that WebGL IDL is not saying [[AllowResizable]], I think this behavior is expected. (bufferData does not have [[AllowResizable]]).

On the other hand,

> I discovered this in a game jam entry I made (https://ianjk.com/ld52/) that I was testing in the Safari Technology Preview. For some reason the SharedArrayBuffer backing the WebAssembly binary is automatically made 'growable' in Safari Technology Preview 160. In Safari 16.2 that does not happen so both the attached example and my game jam entry run fine.


This is fixed in bug 249635.

*** This bug has been marked as a duplicate of bug 249635 ***
Comment 5 Kenneth Russell 2023-01-09 15:33:43 PST
For what it's worth I think the WebGL IDL should be updated to add [AllowResizable] for compatibility with WebAssembly applications that use resizable memory. Have filed https://github.com/KhronosGroup/WebGL/issues/3510 about this.