Bug 229404 (webglcleanup) - WebGL has a lot of #if USE(ANGLE) blocks, making it hard to maintain
Summary: WebGL has a lot of #if USE(ANGLE) blocks, making it hard to maintain
Status: RESOLVED CONFIGURATION CHANGED
Alias: webglcleanup
Product: WebKit
Classification: Unclassified
Component: WebGL (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on: 229402 229405
Blocks: gcgranglecleanup
  Show dependency tree / graph
 
Reported: 2021-08-23 03:35 PDT by Kimmo Kinnunen
Modified: 2024-01-17 02:07 PST (History)
11 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kimmo Kinnunen 2021-08-23 03:35:13 PDT 
WebGL has a lot of #if USE(ANGLE) blocks, making it hard to maintain

There are 3 major implementations for WebGL:
- OpenGL
- OpenGL ES
- ANGLE

The WebGL layer should not #ifdef around these variations, rather the differences should be abstracted somehow so that the WebGL implementation is easier to maintain correctly.
Comment 1 Kimmo Kinnunen 2021-08-23 03:40:24 PDT 
In my personal opinion, it is only viable to run WebGL correctly with the ANGLE implementation. 

The simplest option to fix this bug, option A, would be to:
1) remove all WebGL-related code that is not inside #if USE(ANGLE).

The other option, option B, would be to:
1) Move GCGL ANGLE implementation to GraphicsContextGLANGLE
2) Move #if !USE(ANGLE) code from WebGL to GraphicsContextGLOpenGL

However, option B has the problem that TextureMapper uses GraphicsContextGLOpenGL, and it's not entirely clear to me if it's expected to work on ANGLE and OpenGL or just on OpenGL. If it's the latter, then the task is a bit simpler. If the former, then it's more work.
Comment 2 Kimmo Kinnunen 2021-08-23 03:42:34 PDT 
Hironori, would you have idea what is expected of TextureMapper, and/or who could give opinion on whether or not WebGL should work for non-Cocoa WebKit without ANGLE.
Comment 3 Fujii Hironori 2021-08-23 05:19:46 PDT 
WinCairo finished USE_ANGLE migration. As far as I know, Igalia is working on the migration for GTK and WPE ports. (Bug 225563 comment 6).
WebGL should  work for them without ANGLE until Igalia finishes the migration.

WinCairo is using TextureMapper with ANGLE and GraphicsLayerTextureMapper.
GTK and WPE ports are using TextureMapper with OpenGL and GLES and CoordinatedGraphicsLayer.
Comment 4 Radar WebKit Bug Importer 2021-08-30 03:36:16 PDT 
<rdar://problem/82517622>
Comment 5 Alejandro G. Castro 2021-11-23 13:28:09 PST 
(In reply to Fujii Hironori from comment #3)
> WinCairo finished USE_ANGLE migration. As far as I know, Igalia is working
> on the migration for GTK and WPE ports. (Bug 225563 comment 6).
> WebGL should  work for them without ANGLE until Igalia finishes the
> migration.
> 
> WinCairo is using TextureMapper with ANGLE and GraphicsLayerTextureMapper.
> GTK and WPE ports are using TextureMapper with OpenGL and GLES and
> CoordinatedGraphicsLayer.

Yes, we are currently working in a solution with ANGLE as the WebGL backend. We started checking and updating the current code.
Comment 6 Kimmo Kinnunen 2022-08-17 04:18:17 PDT 
Ping, any progress on removing non-ANGLE WebGL codepaths?
Any place you would need help with that I would be able to contribute?
Comment 7 Zan Dobersek 2022-08-17 04:57:40 PDT 
The desire is to make the switch after next release branching. That event is a matter of 1-2 weeks.

In addition to that there's certain testing environment issues that still need resolving under the GTK port, but that's possibly addressable after turning ANGLE on.
Comment 8 Don Olmstead 2022-08-17 13:36:40 PDT 
Could we have a discussion on this plan before moving forward?
Comment 9 Myles C. Maxfield 2022-08-19 14:31:25 PDT 
This is being discussed in the #angle channel of the open source webkit slack workspace.
Comment 10 Kimmo Kinnunen 2024-01-17 02:07:41 PST 
Thhe ANGLE ifdef blocks are gone