ANGLE (Almost Native Graphics Layer Engine) translates OpenGL ES to pretty much all native graphics APIs: Metal on MacOS and iOS, DirectX on Windows, Vulkan on Linux and Android.
It is developed by Google, is liberally licensed, and used by Safari, Chrome, Firefox, Qt 5, Godot, Cocos2d, etc.
Apple, as everybody knows, deprecated OpenGL half a century ago, so integrating ANGLE would let OpenGL ES code continue to work even after Apple finally pulls the plug. It also apparently provides a very significant performance boost (3x or 4x) on Apple M processors.
I’ve also seen people claim recently that OpenGL ES + ANGLE are far more reliable on Windows than using Desktop OpenGL. And it seems to also help with debugging: instead of getting some cryptic driver crash one can see where in ANGLE a misused function broke.
Integrating ANGLE seems quite straightforward and the change would be transparent for JUCE users as no API changes would be needed. It would simply mean that one could write OpenGL ES code and be confident that it will run without issues everywhere and permanently.
Note that Apple use ANGLE themselves in WebKit/Safari and were involved in developing the METAL backend.
Here are some interesting links. The first is an example of someone who integrated ANGLE with Raylib and was very impressed by the performance on devices with M1/M2 chips:
Many developers (myself included) have not looked into learning OpenGL mostly because of concerns about its deprecation. So they make do with what JUCE has to offer, which is for the most part limited to the CPU and therefore for truly attractive visualizations quite limiting.
A Vulkan module is the second most voted feature request. It would allow rendering Vulkan to a JUCE window, just like the OpenGL module currently does. But is it really necessary? Is Vulkan vastly superior, or easier to use, than OpenGL ES? If not I would prefer the juce team to make the latter work properly and only work on a Vulkan module when/if they have enough resources.
ANGLE has been used in Chrome on Windows for years, and it’s been converted quite successfully to MacOS and iOS. If you can see any of the shaders on www.shadertoy.com then there’s a high chance you’re using ANGLE.
It has been tested thoroughly by lots of web browsers. ANGLE is worth a look.
If you’re using Firefox/Safari/Chrome then all the text you are reading now is being rendered through ANGLE.
What is the downside to using a JavaScript library like Three.js with web view as opposed to Vulkan or Angle? I am fairly new to all of this so bear with me if this is something basic!
ANGLE: allow users of multiple operating systems to seamlessly run WebGL and other OpenGL ES content by translating OpenGL ES API calls to one of the hardware-supported APIs available for that platform
Slang: Slang is a shading language that makes it easier to build and maintain large shader codebases in a modular and extensible fashion, while also maintaining the highest possible performance on modern GPUs and graphics APIs.
Anyway, I would love to hear what JUCE team thinks about these (and other alternatives).
Three and others use WebGL. WebGL runs in your browser because ANGLE converts it to native Metal or DirectX depending on your OS. The idea is to use ANGLE directly, instead of relying on a browser.
ANGLE is a fairly chunky dependency with a complicated build system. I’m not sure if the official version is even set up to build static libs, which is generally preferable for plugins. I would say a cross platform backend using WebGPU native via Google Dawn is a more interesting proposition (which has similar challenges)
Also it’s not clear to me if Apple really intend to remove OpenGL support. They seem to have a pretty capable OpenGL emulator.
In the first link I posted, the author shows two approaches: compiling ANGLE, which he does in just a few steps, or simply heisting the libraries from within the Chrome browser. These are libEGL.dylib and libGLESv2.dylib (with respectively 491KB and 15MB on macOS).
WebGPU sounds great, too, but wouldn’t it be considerably more work for the JUCE team to implement?
If you don’t already know why taking the libraries from a Chrome installation is a bad idea, here’s a video that shows you some of the subtle, extremely hard to debug, pain you could encounter:
Along similar lines, have you actually tried to build ANGLE yourself? A couple of years ago it took me multiple days to work out what dependencies and features were actually needed, work around compilation errors in others, get the minimum deployment target somewhere acceptable, and think about how I could fit the gn based build system into what we already have. This was also following the advice of someone suggesting “just enable these flags and build”. Maybe things have improved recently, but the build complexity should not be underestimated.
I think integrating would be a really big task, and it likely would include API changes to make it work as expected.
As Oli suggests, I think a much better approach is supporting WebGPU. I periodically look at Dawn (which suffers worse compilation issues than ANGLE) but there is also the Rust project wgpu. WebGPU certainly looks like a better target to ensure some degree of future-proofing, but at the moment the complexity of integration, and the somewhat moving target of what’s supported in terms of actual deployment, means it’s not obviously a good investment of our resources at the moment.
Oh, that’s a shame. No, I haven’t actually tried to build ANGLE myself. I guess that settles it then, I underestimated the whole thing. Thanks for the answer, Tom.
It was good to learn that the JUCE team had already looked into ANGLE and that there were good reasons to not support it (I should have known, tbh). WebGPU does sound great. I see that the Rust wgpu project supports GLSL shaders, that these “can be used with any backend as we handle all of the conversions” and “support for these shader inputs is not going away”. That’s very reassuring. Happy Christmas to you all!
