GtkGLArea doesn't work on GLES-only systems
Output:
$ GDK_DEBUG=opengl ./demos/gtk-demo/gtk4-demo --run=glarea
** Message: 03:45:45.245: For syntax highlighting, install the “highlight” program
Gdk-Message: 03:45:45.769: EGL API version 1.4 found
- Vendor: Mesa Project
- Version: 1.4
- Client APIs: OpenGL OpenGL_ES
- Extensions:
EGL_ANDROID_blob_cache
EGL_ANDROID_native_fence_sync
EGL_EXT_buffer_age
EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers
EGL_EXT_pixel_format_float
EGL_EXT_swap_buffers_with_damage
EGL_KHR_cl_event2
EGL_KHR_config_attribs
EGL_KHR_create_context
EGL_KHR_create_context_no_error
EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses
EGL_KHR_gl_colorspace
EGL_KHR_gl_renderbuffer_image
EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_3D_image
EGL_KHR_gl_texture_cubemap_image
EGL_KHR_image_base
EGL_KHR_no_config_context
EGL_KHR_reusable_sync
EGL_KHR_surfaceless_context
EGL_KHR_swap_buffers_with_damage
EGL_KHR_wait_sync
EGL_MESA_configless_context
EGL_MESA_drm_image
EGL_MESA_image_dma_buf_export
EGL_MESA_query_driver
EGL_WL_bind_wayland_display
EGL_WL_create_wayland_buffer_from_image
- Selected fbconfig: R8G8B8A8
high depth: none
Gdk-Message: 03:45:45.769: Creating EGL context version 3.2 (debug:no, forward:no, legacy:no, es:no)
Gdk-Message: 03:45:45.769: Creating EGL context version 2.0 (debug:no, forward:no, legacy:no, es:yes)
Gdk-Message: 03:45:45.773: Created EGL context[0xaaaadbe4a740]
Using OpenGL backend EGL
Gdk-Message: 03:45:45.773: Creating EGL context version 2.0 (debug:no, forward:no, legacy:no, es:yes)
Gdk-Message: 03:45:45.774: Created EGL context[0xaaaadba5a800]
Gdk-Message: 03:45:45.784: OpenGL ES version: 2.0 (core)
* GLSL version: OpenGL ES GLSL ES 1.0.16
* Extensions checked:
- GL_KHR_debug: yes
- GL_EXT_unpack_subimage: yes
- OES_vertex_half_float: yes
Gdk-Message: 03:45:45.784: OpenGL ES version: 2.0 (core)
* GLSL version: OpenGL ES GLSL ES 1.0.16
* Extensions checked:
- GL_KHR_debug: yes
- GL_EXT_unpack_subimage: yes
- OES_vertex_half_float: yes
Gdk-Message: 03:45:45.961: Creating EGL context version 3.2 (debug:no, forward:no, legacy:no, es:no)
Gdk-Message: 03:45:45.961: Creating EGL context version 3.0 (debug:no, forward:no, legacy:yes, es:no)
Notice there's no Creating EGL context version 2.0 (debug:no, forward:no, legacy:no, es:yes)
line at the end - and so we get the error.
This looks like a regression somewhere in !4687 (merged)
I can't completely bisect it because those commits don't build, but it's one of these:
commit c4feca13118fa4a1e2d263c76458fa60de9a608e
Author: Pablo Correa Gómez <ablocorrea@hotmail.com>
Date: Mon May 30 20:18:15 2022 +0200
glcontext: Simplify get_required_version api
Simplify the API to just return the requirements that the user
has asked for. The rest of the code was undocumented and previously
used as a buggy source for a default value from internal code.
Since the buggy code is now fixed, remove all unnecessary cruft.
commit 9426b20759d81673ccecf0de35d307878acdddcf
Author: Pablo Correa Gómez <ablocorrea@hotmail.com>
Date: Wed May 25 15:23:38 2022 +0200
glcontext: Do not check for correctness in set_required_version
There are two reasons for this:
* First, the refactored realize code now makes sure that no
context with unsupported version is ever created.
* Second, this code could bump into false possitives and negatives, since
the user is not requested, nor expected to set_required_version
in any specific order relative to set_allowed_apis. Therefore,
some version could be rejected or accepted based on a set of
allowed apis that the user has not yet correctly configured.
commit f97cff14541d0d24637a2971db1589e707baaedf
Author: Pablo Correa Gómez <ablocorrea@hotmail.com>
Date: Mon May 30 21:11:28 2022 +0200
glcontext-glx: Refactor realize function
Mimic the behavior of the egl context creation by stablishing
some sane logic for the api and version used. Split the decision
of the type of context (api, legacy) and the creation of a context
of a certain version and all its properties.
commit 549a2b4c866e988b791244ca5d67d16bdbf5e006
Author: Pablo Correa Gómez <ablocorrea@hotmail.com>
Date: Fri May 6 21:43:30 2022 +0200
glcontext: Refactor realize function, fix interaction with shared context
commit f4f0daa113ecd8bdec4e1f09cd00407c648650c3
Author: Pablo Correa Gómez <ablocorrea@hotmail.com>
Date: Sat May 28 01:01:19 2022 +0200
macosglcontext: Do not rely on default from get_required_version
get_required_version cannot warranty to return any default. Instead,
fetch the user requisites clipped by the requirements in our backend.
commit d4f8a80f2a3d1043a37a69c2302b8293b48a4165
Author: Pablo Correa Gómez <ablocorrea@hotmail.com>
Date: Sat May 28 00:58:43 2022 +0200
glcontext-win32-wgl: Respect user required version, use display as minimum
By setting and then getting the required version in a context, the code
was not respecting user requirements. Instead, simply get the requested
version by the user clipped by the requirements (display version)
commit 8d175801d73612b1ca49e9fd47c3c0fed17c7552
Author: Pablo Correa Gómez <ablocorrea@hotmail.com>
Date: Mon May 30 20:14:53 2022 +0200
glcontext: Add internal get_clipped_version function
It is useful for backends to get user set preferences while
ensuring the correctness of the result, which will be always
greater or equal than the minimum version provided
After a bit of debugging, it's the
if (!gdk_gl_context_is_api_allowed (context, api, NULL))
return 0;
check in gdk_gl_context_create_egl_context()
. Removing that check makes it work.
If GLES is available and GL is not, and preferred_api
in gdk_gl_context_realize_egl()
is GDK_GL_API_GL
, then
if ((api = gdk_gl_context_create_egl_context (context, GDK_GL_API_GL, prefer_legacy)) ||
(api = gdk_gl_context_create_egl_context (context, GDK_GL_API_GLES, FALSE)) ||
(api = gdk_gl_context_create_egl_context (context, GDK_GL_API_GL, TRUE)))
return api;
here the GLES call bails because of the gdk_gl_context_is_api_allowed()
check, and both GL calls fail as it's not available - and we get Unable to create a GL context
.
How preferred_api
ends up being GL when gdk_gl_context_is_api_allowed()
later fails with it - IDK.