OpenGL works badly on MacOS and even worse on Windows unless translated through Angle. On Windows, using OpenGL directly will give performance problems and crashes _all the time_. And weird bugs, like red and blue swap on some combinations of AMD GPU's and driver versions.

> On Windows, using OpenGL directly will give performance problems and crashes _all the time_.

Didn't the original (Java) version of Minecraft use OpenGL? It seems to have done well enough...

Except PlayStation, Android until version 10, Win32 and UWP sandboxing.

> PlayStation

True, but Sony has some sort of completely custom thing going on there so it seems that there's zero chance of standardization in that case.

> Android until version 10

I thought Android got VK support way back in version 7 (Nougat)? And hasn't it always supported GL ES? Not being a closed platform, support for any API is of course dependent on the underlying GPU and associated driver.

> Win32 and UWP sandboxing

TIL. I hadn't realized Microsoft restricted access to Vulkan and GL from within the sandbox. It looks like ANGLE has supported GL ES for Windows Store apps since 2014? Regardless, I was under the impression that UWP wasn't very popular with developers anyway.

Android got optional Vulkan support on version 7, yes. And by being optional, meant most OEMs cared as much as the optional updates.

Hence why on Android 10, Google took a set of actions, made Vulkan mandatory, started the path to have OpenGL ES on top of Vulkan and introduced GPGPU driver updates via the Play Store, as means to force OEMs to actually care about Vulkan.

Just like many devices still don't ship with OpenGL ES 3.x, because it is optional as well.

There a reason why I mentioned Win32 and UWP sandboxing and not just UWP. Yes the pure UWP model although quite nice to program for (for me it is what .NET 1.0 should have been all along) failed to gather the mass adoption that Microsoft hoped for, and that is why since two years they have changed course to merge both worlds, now officially known as Project Reunion.

As a matter of fact, here is the application model for the upcoming Windows 10X, where pico processes are used to sandbox Win32, WSL style, https://youtu.be/ztrmrIlgbIc

Angle for UWP was contributed by Microsoft themselves and now they are working together with Collabora to support OpenGL and OpenCL.

https://github.com/microsoft/angle

https://devblogs.microsoft.com/directx/in-the-works-opencl-a...

Regarding Android, yeah I get that it's optional (I actually didn't know that recent versions had made it mandatory). If you view Android as analogous to Windows though then I think it makes sense. There's lots of different devices running Android, some of which aren't even phones. My point is that, similar to desktop GPUs, you can choose a "lowest common denominator" API based on the maximum age of the physical devices that you want to support.

I don't see a problem with that approach. In fact it seems to be about the best you can hope for when it comes to hardware APIs in general (unless you're Apple and control all the hardware) since things are constantly being revised and redesigned.

Regarding Windows, what are you saying here? That Windows Store apps will be getting Win32 support in the near future because the sandbox will finally be able to accommodate it (but VK and GL will still be blocked)? Or that native (unsandboxed) Win32 apps will become sandboxed (and thus restricted) in the near future? (I suspect the former, which is neat but doesn't change anything regarding graphics APIs.)

I did learn a few new things here but am still left with the general impression that Vulkan has reasonably broad (and increasing) support while OpenGL ES 2.0 can target pretty much everything worth supporting (including most web browsers). (Of course I'd strongly prefer to use a more modern API than ES 2.0 if it's available.)

The difference is that desktops get updates, while on Android is more of wishful thinking targeting latest versions, unless one just targets Pixel and Samsung flagship devices.

Win32 sandboxing is orthogonal to the store.

UWP is not about the store, people keep mixing this up, as it unfortunely refers to multiple things across the Windows stack.

UWP is also known as WinRT, UAP, or just modern COM. And sandboxing UWP applications doesn't necessarly require delivery via the store. Any MSIX package will do.

What Microsoft is now doing (officially as of Reunion) is detaching all this tech from the kernel and have them as userspace APIs, across multiple Windows versions, and merging the UWP and Win32 stacks into one, hence Project Reunion.

Sandboxed Win32 applications don't need to be store only.

>Vulkan seems to work pretty much everywhere (except Apple of course).

There's Molten.

Indeed, which is now managed by Khronos itself.