[Webkit-unassigned] [Bug 223637] Only use system's OpenGL ES directly when WebGL is disabled

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Mar 31 12:18:47 PDT 2021


https://bugs.webkit.org/show_bug.cgi?id=223637

--- Comment #4 from Don Olmstead <don.olmstead at sony.com> ---
(In reply to Kenneth Russell from comment #2)
> Keep in mind that ANGLE provides uniform, consistent and conformant OpenGL
> ES semantics even when hosted on top of OpenGL ES itself. It papers over
> dozens if not hundreds of driver bugs found on various platforms, and can
> add value even if not used directly for WebGL.

I'm not trying to detract from the amazing work the folks working on ANGLE have done over the years. I do understand the benefits of using ANGLE as an OpenGL ES implementation.

Our situation is that we have an embedded device with a home grown OpenGL ES implementation. On PlayStation 5 we don't support WebGL and don't have plans to. On PlayStation 4 we have a handful of legacy apps that use WebGL 1 but we do not expose WebGL to the world at large.

This puts us into a position where ANGLE, even its compiler, is just pure overhead.

So I envision the following for when ANGLE is used in WebKit

Apple - Always USE_ANGLE
Desktop GL - Always USE_ANGLE
OpenGL ES - USE_ANGLE only if ENABLE_WEBGL (unless explicitly told not to USE_ANGLE *means can't do WebGL 2*)

This means we can collapse things down in platform so there's always an OpenGL ES implementation that's either provided by ANGLE or the system.

That make more sense? I can try and elaborate more. Also I can change the component if you all don't think this is WebGL. Maybe just platform or ANGLE.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210331/8e1bb144/attachment.htm>


More information about the webkit-unassigned mailing list