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

[bugzilla-daemon at webkit.org]

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

--- Comment #7 from Kenneth Russell <kbr at google.com> ---
(In reply to Don Olmstead from comment #4)
> 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.

:( While of course it isn't close to the primary use case for the PlayStation platform, it would be really nice if the PS5's web browser would support WebGL. Given the experience our team's gathered from sandboxing and validating WebGL, this seems achievable from the technical side.

> 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.

OK, understood.

> 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*)

Understood and agreed on all of these, except I don't understand the "unless explicitly told not to USE_ANGLE *means can't do WebGL 2*" parenthetical comment. Could you rephrase this?

USE_ANGLE on top of OpenGL ES 3.0 certainly supports WebGL 2. That's the configuration that has been enabled on iOS builds for several months now. WebGL 2 context creation will fail at runtime if OpenGL ES 3.0 isn't supported, for example on OpenGL ES 2.0-only devices.

> 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.

Yes, makes sense modulo the question above.

-- 
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/20210401/199b5a4c/attachment-0001.htm>