This is motivated by the work in GTK master for Windows (part of MR !3726 (merged)) where we try to create different GObjects based on whether we are using WGL or EGL/GLES (libANGLE), so to:
Make the code more readable, by reducing the number of
#ifdef's in the code, and grouping WGL-specific code and EGL-specific code together respectively. This means that we are more clear on the codepaths that we go into for WGL and GLES
Make things easier to add a fallback mode to use GLES in case the ICD drivers for Windows do not support OpenGL well enough (notably older Intel drivers where only the GL 1.1 features are exposed by it, for instance).
So, at this point:
The program will no longer crash with a
GL implementation doesn't support any form of non-power-of-two texturesmesage in the console, but show a message that a GL implementation is not available when attempting to run
GdkGLContextitems with GLES being requested (or being used as a fallback) when GLES support is not enabled in the build.
Headers and code should be more streamlined, as we subclass
GdkWin32GLContextinto WGL and EGL/GLES contexts at the GObject level. Unneeded prototypes are also removed from the headers as well.
Check whether the graphics drivers support GL well enough for our uses in GTK--currently we require that it is capable of handling shader objects in the GDK backend level, which can also pave the way to blacklist drivers if needed in the future. If we find that the GL support provided by the driver is inadequate, we try again creating the
GdkGLContextusing GLES, if support is enabled during build time.
We keep but disable the code on checking on whether we are running on ARM64 Windows. The reasoning is that Microsoft provided a build for Mesa in Microsoft Store for ARM64 Windows with the recently-added D3D12 drivers, which should support our Desktop OpenGL uses well enough on ARM64 Windows. GDK can now check whether the ARM64 system has enough support for Desktop OpenGL before attempting to fall back to GLES, which was formerly the only code path on ARM64 Windows.
Much of this is already in GTK4 via MR !3726 (merged), except perhaps where we automatically fallback to GLES when the WGL support in the driver is inadequate.
With blessings, thank you!