`ANGLE` for iOS (looks) ready, and Apple urges devs to migrate away from `OpenGLES.framework`. Time for a switch?

[misl6]

Hello everyone!

Has been (almost) a couple of years after I did my first iteration over "making sure there's a continuity, even after Apple takes the toughest decision" (See: #4333)

I can only agree with the decision to stick with the OpenGLES.framework until something robust and mature (like ANGLE, the official one) is ready.

And finally, something seems to have changed:

• ANGLE switched from inprogress to complete for iOS Metal backing renderer some months ago. (See: https://github.com/google/angle)
• Apple is reportedly using ANGLE in Webkit to support WebGL things. (See: https://github.com/WebKit/WebKit/tree/main/Source/ThirdParty/ANGLE)

... so, it's definitely time for a switch? (Or at least, a parallel implementation, since iOS < 12 does not support Metal, even if most modern apps can likely survive without supporting iOS <= 11, which is also not available anymore as a minimum deployment target in XCode 15 😅)

What are SDL devs thoughts?
Is there already something scheduled? (in SDL3)

IMHO, switching (or adding a new implementation) to ANGLE in UIKit, is something that needs to be scheduled before the next major iOS update, as even if we're still safe in iOS 17, there's no guarantee that the next iOS version will still have support for OpenGLES.framework, and having a plan B before that happens, is important for continuity for apps (and frameworks) that are using this feature.

[icculus]

I think we should explore this now that upstream ANGLE is in better shape.

Is any of your previous patch salvageable at this point?

[misl6]

Is any of your previous patch salvageable at this point?

I do not think so, as ANGLE does not have MGLKit that mimics Apple's deprecated EAGL & GLKit API. (MetalANGLE had this feature).

Looking at how has been used in WebKit could help: https://github.com/WebKit/WebKit/tree/main/Source/WebCore/platform/graphics/cocoa

Or, having a reboot of the MGLKit as described here seems a reasonable idea (I think the author is okay if someone wants to take over).

[SasLuca]

I've been trying to use SDL3 with ANGLE recently but when I link libEGL and libGLESv2 to SLD3 ios app via cmake, I just get a (null) opengles context.

Is ANGLE just not usable with SDL3 at the moment on iOS or is it possible I am having some other issue? On Windows I was able to use ANGLE just fine via SDL3.

[misl6]

@SasLuca FYI, that's how we implemented ANGLE support on top of SDL2 (but also SDL3, with minor changes) at Kivy:
kivy/kivy#8534

So, yes, it's possible but requires some additional code.

[SasLuca]

@misl6 Thanks for the reply. I got angle to work on ios with a custom swift app without SDL where I create a metal view myself and then load opengles with angle's egl. From what I am seeing in your kivy code, to get angle to work with SDL3 you tell init the window without SDL_WINDOW_OPENGL on ios and then create a metal view from SDL3 and pass that later to angle's egl to init the gl context, right?

I will try to do this with SDL3 and see if I can get it to work and if so I might post a repo to help others. If SDL3 bundled it's own precompiled iOS ANGLE binaries and did everything for us behind the scenes in the future tho that would be very cool. I recently had issues with opengl es on iOS that got fixed by simply using ANGLE so it's possible OpenGLES.framework has some bugs that Apple will never fix.

[SasLuca]

I managed to get ANGLE working with SDL3! Thanks a lot @misl6.

Here is how I did it:
https://gist.github.com/SasLuca/307a523d2c6f2900af5823f0792a8a93