Commit Graph

14 Commits

Author SHA1 Message Date
Chun-wei Fan
38c17c1f79 gdkglcontext-win32-wgl.c: Cleanup GL context creation
Instead of first trying to explicitly ask for a WGL 4.1 context, ask for
the WGL context version that matches what is reported via
epoxy_gl_version(), so that we get the maximum WGL version that is
supported by the graphics drivers, and make sure any WGL contexts that
are shared with this (initial) WGL context are created likewise.

We can try to do a default-bog-standard 3.2 core WGL context creation
if the need arises, but let's leave that alone for now.
2022-01-19 11:56:32 +08:00
Chun-wei Fan
598c7d9cf4 GDK/Win32: Try to fix initializing GLES contexts
We are now able to create EGL contexts properly on Windows, but not GLES.  This
tries to fix things by doing the following:

*  Record the GL context type in a more proper fashion, using an Enum.  This
   makes things a bit cleaner.
*  Force GLES-3.0+ contexts, since libANGLE requires this to properly work with
   the shaders-its 2.0 contexts don't work well with our shaders.
2022-01-19 11:56:32 +08:00
Chun-wei Fan
048fe84888 GDK-Win32: Port to common EGL handling code
This will port the EGL code in GDK-Win32 to use the common GDK code to
initialize EGL.  However, at the current state, although EGL is
correctly initialized, this code is disabled for now since
gdk_gl_context_make_current() fails as the shaders do not work for EGL
via libANGLE on Windows.

We can now clean things up in gdkglcontext-win32-egl.c as a result.
2021-11-08 15:25:24 +08:00
Benjamin Otte
f584d4f500 gl: Check allowed APIs in realize()
Add gdk_gl_context_is_api_allowed() for backends and make them use it.

Finally, have them return the final API as the return value (or 0 on
error).

And then use that api instead of a use_es boolean flag.

Fixes #4221
2021-10-08 03:31:07 +02:00
Benjamin Otte
dc6e831524 gdk: hdr => high depth
The term "hdr" is so overloaded, we shouldn't use them anywhere, except
from maybe describing all of this work in blog posts and other marketing
materials.

So do renames:
* hdr => high_depth
* request_hdr => prefers_high_depth

This more accurately describes what is going on.
2021-10-06 22:50:07 +02:00
Benjamin Otte
7ede468849 gdk: Add a request_hdr argument to begin_frame()
It's not used by anyone, it's just there.

gdk_draw_context_begin_frame_full() has been added so renderers can
make use of it.
2021-10-06 03:44:58 +02:00
Matthias Clasen
2a3a1aaf1e Merge branch 'fix-wgl-cairo-fallback' into 'master'
Apply MR !3964 to master (fix WGL->Cairo fallback-related items)

Closes #4257

See merge request GNOME/gtk!3987
2021-10-01 00:29:40 +00:00
Benjamin Otte
d4f9d38368 win32: Fix gcc warnings 2021-09-24 22:50:29 +02:00
Benjamin Otte
226ecaf9a2 win32: Don't include gdkinternals.h 2021-09-24 22:50:29 +02:00
Benjamin Otte
23acc993cc gdk: Make sure only one GL backend is used
Creative people managed to create an X11 display and a Wayland display
at once, thereby getting EGL and GLX involved in a fight to the death
over the ownership of the glFoo() symbolspace.

A way to force such a fight with available tools here is (on Wayland)
running something like:
GTK_INSPECTOR_DISPLAY=:1 GTK_DEBUG=interactive gtk4-demo

Related: xdg-desktop-portal-gnome#5
2021-09-24 01:59:37 +02:00
Chun-wei Fan
218a3e3d01 gdkglcontext-win32-wgl.c: Fix Cairo fallback check
We were setting the WGL pixel format in GdkWin32Display too early, so the code
does not bail out correctly when we retry establishing the WGL context.

Fix this by pushing back setting the WGL pixel format only after it passes the
shader availability check.

Should fix issue #4257.
2021-09-22 11:08:53 +08:00
Chun-wei Fan
5d0f188615 GDK-Win32: Reject WGL context if shaders aren't supported
When we initialize OpenGL, check whether we have OpenGL  2.0 or later; if not,
check whether we have the 'GL_ARB_shader_objects' extension, since we must be
able to support shaders if using OpenGL for GTK.

If we don't support shaders, as some Windows graphics drivers do not support
OpenGL adequately, notably older Intel drivers, reject and destroy the GL
context that we created, and so fallback to the Cairo GSK renderer, so that
things continue to run, albeit with an expected warning message that the GL
context cannot be realized.

Also, when we could not make the created dummy WGL context current during
initialization, make sure that we destroy the dummy WGL context as well.

Fixes issue #4165.
2021-08-17 16:25:09 +08:00
Chun-wei Fan
8648486400 GDK-Win32: Fixup, and cleanup WGL HDC handling
It turns out that the problem of the WGL window not drawing was due to
the fact that I messed up where I placed SwapBuffers() during the
conversion... doh:|

At the same time, stop storing the HDC in the GdkWin32GLContextWGL, but
instead always create it along the surface we created, so that it is ready
for use for operating with WGL when we are not dealing with "surfaceless"
contexts.  If we are dealing with "surfaceless" contexts, just use the
HDC of the dummy window that we created when we created the
Gdk(Win32)Display.

WGL contexts should now be in working order at this point.
2021-07-22 16:28:16 +02:00
Chun-wei Fan
6c00117119 Split out WGL/EGL stuff and simplify things
This commit attempts to split GdkWin32GLContext into two parts, one for
WGL and the other for EGL (ANGLE), and attempts to simplify things a
bit, by:

*  We are already creating a Win32 window to capture display changes,
   so we can just use that to act as our dummy window that we use to
   find out the pixel format that the system supports for WGL.  We also
   use it to obtain the dummy legacy WGL context that we will always
   require to create our more advanced Core WGL contexts.

*  Like what is done in X11, store up the WGL pixel format or the
   EGLConfig in our GdkWin32Display.

*  Ensure we do not create the dummy WGL context unnecessarily.

In this way, we can successfully create the WGL/EGL contexts, however
there are some issues at this point:

*  For WGL, the code successfully initializes and realizes the WGL
   Contexts, but for some reason things became invisible.  When running
   gtk4-demo, this can be verified by seeing the mouse cursor changing
   when moved to spots where one can resize the window, although they
   were invisible.

*  For EGL, the code initializes EGL but could not realize the EGL
   context as shaders failed to compile.  It seems like the shader issue
   is definitely outside the scope of this MR.
2021-07-22 16:28:16 +02:00