<rdar://problem/110163403>

Pull request: https://github.com/WebKit/WebKit/pull/14623

Blocks bug 252876 for benchmarking before/after read pixels perf

The side-effects of flush() and finish() can't be observed by application code in the WebGL context. Even with finish(), there's a WebGL spec difference compared to OpenGL ES that the status of objects like queries can't change unless control is returned to the browser. For this reason it should be safe to leave these asynchronous, and I think WebKit might incur a performance penalty compared to other implementations by making them synchronous. If it's necessary to use these for synchronization with other subsystems in WebKit like the media stack, I'd suggest adding another internal primitive that can't be called by the web platform - Chromium does this.

Think Chrome's implementation is also synchronous, e.g. the call between renderer and GPU process.
I think previously we discussed wrt "real finish vs gl.finish as gl.flush()", which cannot be observed.

Or, maybe not maybe it is indeed async?

In Chrome at the lowest level, Finish is synchronous:
https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:gpu/command_buffer/client/cmd_buffer_helper.cc;l=220;drc=b8a0323a84f483b25e94b3a24d80fda16c5dd1ae;bpv=1;bpt=1

but Flush isn't:
https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:gpu/command_buffer/client/cmd_buffer_helper.cc;l=173;drc=b8a0323a84f483b25e94b3a24d80fda16c5dd1ae;bpv=0;bpt=1

However, the WebGL implementation never calls the underlying Finish, only Flush:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc;l=3034?q=webgl_rendering_context_base.cc

> However, the WebGL implementation never calls the underlying Finish, only Flush:

Ah, right! I keep on forgetting.