Closed zmerp closed 1 year ago
Thanks! Can you justify the decision to select GL ES automatically iff targeting Android? Does Android not support regular OpenGL? Does this require the user to adjust the extensions they enable depending on whether building for Android?
OpenGL is for desktop and OpenGL ES is for embedded, they are mutually exclusive. Furthermore, the OpenXR documentation says that the XR_KHR_opengl_es_enable
extension is tailored for android at the moment. You can use an abstraction layer over the two APIs (like the glow Rust crate) but EGL code is still platform-specific.
Does this require the user to adjust the extensions they enable depending on whether building for Android
Yes
Then there's no point trying to pretend OpenGL and OpenGL ES are the same thing. Let's expose a separate Graphics
impl instead.
Then there's no point trying to pretend OpenGL and OpenGL ES are the same thing. Let's expose a separate Graphics impl instead.
The reason behind this is, as I said, they are mutually exclusive, and also they can share some of the wrapper code, but that's a fair point. I will make a separate Graphics implementation.
Thanks! Should be able to review properly within a few days.
they are mutually exclusive
I don't think this is actually true. For example, Mesa's implementation should work just fine on desktop Linux, and targeting it might be desirable for testing or portability.
I don't think this is actually true
Yeah, they are both open standards and in particular OpenGL ES is preferred as a common denominator and wrapper layer since it is mostly a subset of OpenGL (see Google ANGLE). And Mesa being opensource can do what it wants. In any case the OpenXR documentation says XR_KHR_opengl_es_enable
is Android only. We can relax this restriction once there is really support for other non-Android platforms for this extension.
Tested with https://github.com/alvr-org/ALVR/tree/openxr-client/alvr/client_openxr .