== ANGLE and WebGL 2.0 in WebKit ==
''by @dino (Apple), @James Darpinian (Google), @Kimmo Kinnunen (Apple)'' [https://docs.google.com/presentation/d/1ilUE_r5WNGlRhfGx71XH1E3CdTEpN1btGiQF4808AC8/edit?usp=sharing 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