ANGLE and WebGL 2.0 in WebKit

by @dino (Apple), @James Darpinian (Google), @Kimmo Kinnunen (Apple) ​Slide Deck

WebKit has integrated the ANGLE project as its primary WebGL backend, significantly improving compatibility with other browsers, and enabling a conformant WebGL 2.0 in WebKit. This talk describes how ANGLE works from WebKit’s perspective, status of the project, and offers advice to other ports on switching to ANGLE.

kbr: Talks about background. Mentions that WebGL2 shipped in 2017 in Firefox and Chrome, but not on iOS. WebGL1 only gained traction with iOS implementation, so iOS support for WebGL2 is important

kbr: Some desire for WebGPU to be baseline, but requires more capable hardware (WebGL1 is the current baseline)

kbr: Implementation is not as simple as just exposing raw API, due to requirement for it to work the same across all platforms - requires lots of validation checks and such

kbr: ANGLE does this for us

kbr: ANGLE is an OpenGL ES implementation on top of other APIs: D3D, GL, GLES, Vulkan and Metal (last is very recent)

kbr: ANGLE exposes GLES 3.0, 3.1, 3.2 API and has built-in support for WebGL 1 and 2

kbr: Easiest path to WebGL2 in WebKit - implement WebGL via ANGLE, finish WebGL2 JS bindings - project started in June 2019

kbr: WebKit uses internal ANGLE API to avoid API collisions with system-level GL libraries

kbr: ANGLE has internal optimisation of GL state changes, giving big potential performance improvements

kbr: ANGLE updating in WebKit is largely automated, except for Xcode project file update

kbr: ANGLE has been improved due to work on its integration in WebKit

kbr: per-platform code is necessary to integrate with the browser compositor, video stack, etc. - we will discuss Mac and iOS

kbr: Explaining class hierarchy (see slides)

smfr: Some of this code is being heavily refactored due to the GPU process work

kbr: these code links may/will be obsoleted pretty soon - hopefully this presentation isn't negatively useful, but we'll try to keep it up-to-date

kbr: Video-to-webgl-texture performance is important - handled by GraphicsContextGLCVANGLE

kbr: With EGL, the context must be current only in one thread at a time - this restriction isn't there on iOS

kbr: Multi-threading problems exist in the WK1 execution model and care must be taken, these problems don't exist with the WK2 execution model

kbr: WebGL2 required updating lots of code that can interact with texture uploads, such as ImageBitmap creation, creating textures from DOM elements, etc. - this is done and tested

kbr: WebKit's WebGL2 implementation is passing over 98% of the conformance suite

kbr: WebGL1 under ANGLE also improved, but no numbers to hand

kbr: goal is 100% conformance on MacOS and iOS - remaining failures are mostly GPU-specific driver bugs that need workarounds

kbr: Lots of sites and demos are working well - we've been collaborating with partners, like Unity, to ensure this

kbr: We'd like all WebKit ports to adopt the ANGLE backend - especially Linux/embedded Linux and Windows

kbr: full ANGLE adoption would allow removal of USE(OPENGL) and USE(OPENGL_ES) #ifdefs, which would be a huge simplification

kbr: OffscreenCanvas support could use ANGLE via GPU process, or otherwise ANGLE would need more multi-threading support

Questions & Comments

clord: Why was the internal API exposure necessary for WebKit, but not for Chrome?

kbr: Chrome dynamically looks up ANGLE symbols so there's zero possibility of collision. To simplify the work and interaction with the WebKit build system, a static linking approach was used.

deanjackson: ANGLE will be dynamically linked into WebCore soon. Everything continues to work as it is, changes aren't required. We could use the Chromium model now, but it isn't urgent.

smfr: OffscreenCanvas, GPUProcess dependencies - do you think you'd disable support until GPUProcess could be used, or would you do the work to make ANGLE usable across multiple threads?

kbr: We'd do the work. Talks about the synchronisation, sounds like a tractable problem.

smfr: If it depended on GPUProcess, it may impose requirements for newer OS versions as GPUProcess may not be supported on older OS versions

kbr: Further reassurance about commitment to getting it to work with OffscreenCanvas on as many platform/OS combinations as possible