AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2025-01-15 06:40:08 +00:00
Code Issues Projects Releases Wiki Activity
fca983e81e
gtk/gdk/win32/gdkglcontext-win32-wgl.c

1207 lines
36 KiB
C
Raw Normal View History

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-14 09:46:31 +00:00
/* GDK - The GIMP Drawing Kit
*
* gdkglcontext-win32.c: Win32 specific OpenGL wrappers
*
* Copyright © 2014 Emmanuele Bassi
* Copyright © 2014 Alexander Larsson
* Copyright © 2014 Chun-wei Fan
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Library General Public License for more details.
*
* You should have received a copy of the GNU Library General Public
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*/
#include "config.h"
#include "gdkprivate-win32.h"
#include "gdksurface-win32.h"
#include "gdkglcontext-win32.h"
#include "gdkdisplay-win32.h"
#include "gdkwin32display.h"
#include "gdkwin32glcontext.h"
#include "gdkwin32misc.h"
#include "gdkwin32screen.h"
#include "gdkwin32surface.h"
#include "gdkglcontext.h"
#include "gdkprofilerprivate.h"
Drop gdkintl.h This header was merely including gi18n-lib.h. Just do that directly.
2022-09-24 03:33:42 +00:00
#include <glib/gi18n-lib.h>
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-14 09:46:31 +00:00
#include "gdksurface.h"
#include <cairo.h>
#include <epoxy/wgl.h>
struct _GdkWin32GLContextWGL
{
GdkWin32GLContext parent_instance;
HGLRC wgl_context;
guint do_frame_sync : 1;
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
guint double_buffered : 1;
enum {
SWAP_METHOD_UNDEFINED = 0,
SWAP_METHOD_COPY,
SWAP_METHOD_EXCHANGE,
} swap_method;
/* Note: this member is only set when
* swap_method is exchange */
cairo_region_t *previous_frame_damage;
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-14 09:46:31 +00:00
};
typedef struct _GdkWin32GLContextClass GdkWin32GLContextWGLClass;
G_DEFINE_TYPE (GdkWin32GLContextWGL, gdk_win32_gl_context_wgl, GDK_TYPE_WIN32_GL_CONTEXT)
static void
gdk_win32_gl_context_wgl_dispose (GObject *gobject)
{
GdkWin32GLContextWGL *context_wgl = GDK_WIN32_GL_CONTEXT_WGL (gobject);
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
g_clear_pointer (&context_wgl->previous_frame_damage, cairo_region_destroy);
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-14 09:46:31 +00:00
if (context_wgl->wgl_context != NULL)
{
GDK-Win32: Add wrapper functions for calling core wgl* functions We might be dealing with GL contexts from different threads, which have more gotchas when we are using libepoxy, so in case the function pointers for these are invalidated by wglMakeCurrent() calls outside of GTK/GDK, such as in GstGL, we want to use these functions that are directly linked to opengl32.dll provided by the system/ICD, by linking to opengl32.lib. This will ensure that we will indeed call the "correct" wgl* functions that we need. This should help fix issue #5685.
2023-03-24 03:08:26 +00:00
if (gdk_win32_private_wglGetCurrentContext () == context_wgl->wgl_context)
gdk_win32_private_wglMakeCurrent (NULL, NULL);
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-14 09:46:31 +00:00
GDK_NOTE (OPENGL, g_print ("Destroying WGL context\n"));
GDK-Win32: Add wrapper functions for calling core wgl* functions We might be dealing with GL contexts from different threads, which have more gotchas when we are using libepoxy, so in case the function pointers for these are invalidated by wglMakeCurrent() calls outside of GTK/GDK, such as in GstGL, we want to use these functions that are directly linked to opengl32.dll provided by the system/ICD, by linking to opengl32.lib. This will ensure that we will indeed call the "correct" wgl* functions that we need. This should help fix issue #5685.
2023-03-24 03:08:26 +00:00
gdk_win32_private_wglDeleteContext (context_wgl->wgl_context);
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-14 09:46:31 +00:00
context_wgl->wgl_context = NULL;
}
G_OBJECT_CLASS (gdk_win32_gl_context_wgl_parent_class)->dispose (gobject);
}
static void
gdk_win32_gl_context_wgl_end_frame (GdkDrawContext *draw_context,
cairo_region_t *painted)
{
GdkGLContext *context = GDK_GL_CONTEXT (draw_context);
GdkWin32GLContextWGL *context_wgl = GDK_WIN32_GL_CONTEXT_WGL (context);
GdkSurface *surface = gdk_gl_context_get_surface (context);
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-19 02:32:28 +00:00
GdkWin32Display *display_win32 = (GDK_WIN32_DISPLAY (gdk_gl_context_get_display (context)));
gboolean can_wait = display_win32->hasWglOMLSyncControl;
HDC hdc;
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-14 09:46:31 +00:00
GDK_DRAW_CONTEXT_CLASS (gdk_win32_gl_context_wgl_parent_class)->end_frame (draw_context, painted);
gdk_gl_context_make_current (context);
gdk_profiler_add_mark (GDK_PROFILER_CURRENT_TIME, 0, "win32", "swap buffers");
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-19 02:32:28 +00:00
if (surface != NULL)
hdc = GDK_WIN32_SURFACE (surface)->hdc;
else
hdc = display_win32->dummy_context_wgl.hdc;
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-14 09:46:31 +00:00
if (context_wgl->do_frame_sync)
{
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-19 02:32:28 +00:00
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-14 09:46:31 +00:00
glFinish ();
if (can_wait)
{
gint64 ust, msc, sbc;
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-19 02:32:28 +00:00
wglGetSyncValuesOML (hdc, &ust, &msc, &sbc);
wglWaitForMscOML (hdc,
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-14 09:46:31 +00:00
0,
2,
(msc + 1) % 2,
&ust, &msc, &sbc);
}
}
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-19 02:32:28 +00:00
SwapBuffers (hdc);
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
context_wgl->previous_frame_damage = cairo_region_copy (painted);
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-14 09:46:31 +00:00
}
GdkWin32: Implement GdkDrawContext::empty_frame() vfunc
2024-01-30 15:20:24 +00:00
static void
gdk_win32_gl_context_wgl_empty_frame (GdkDrawContext *draw_context)
{
}
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
static cairo_region_t *
gdk_win32_gl_context_wgl_get_damage (GdkGLContext *gl_context)
{
GdkWin32GLContextWGL *self = GDK_WIN32_GL_CONTEXT_WGL (gl_context);
if (!self->double_buffered ||
self->swap_method == SWAP_METHOD_COPY)
{
return cairo_region_create ();
}
if (self->swap_method == SWAP_METHOD_EXCHANGE &&
self->previous_frame_damage)
{
return self->previous_frame_damage;
}
return GDK_GL_CONTEXT_CLASS (gdk_win32_gl_context_wgl_parent_class)->get_damage (gl_context);
}
static void
gdk_win32_gl_context_wgl_surface_resized (GdkDrawContext *draw_context)
{
GdkWin32GLContextWGL *self = (GdkWin32GLContextWGL*) draw_context;
g_clear_pointer (&self->previous_frame_damage, cairo_region_destroy);
}
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-14 09:46:31 +00:00
static void
drawcontext: Make begin_frame() set colorstate + depth Make begin_frame() set a rendering colorstate and depth, and provide it to the renderers via gdk_draw_context_get_depth() and gdk_draw_context_get_color_state(). This allows the draw contexts to define their own values, so that ie the Cairo and GL renderer can choose different settings for rendering (in particular, GL can choose GL_SRGB and do the srgb conversion; while Cairo relies on the renderer).
2024-06-30 02:06:48 +00:00
gdk_win32_gl_context_wgl_begin_frame (GdkDrawContext *draw_context,
GdkMemoryDepth depth,
cairo_region_t *update_area,
GdkColorState **out_color_state,
GdkMemoryDepth *out_depth)
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-14 09:46:31 +00:00
{
gdk_win32_surface_handle_queued_move_resize (draw_context);
drawcontext: Make begin_frame() set colorstate + depth Make begin_frame() set a rendering colorstate and depth, and provide it to the renderers via gdk_draw_context_get_depth() and gdk_draw_context_get_color_state(). This allows the draw contexts to define their own values, so that ie the Cairo and GL renderer can choose different settings for rendering (in particular, GL can choose GL_SRGB and do the srgb conversion; while Cairo relies on the renderer).
2024-06-30 02:06:48 +00:00
GDK_DRAW_CONTEXT_CLASS (gdk_win32_gl_context_wgl_parent_class)->begin_frame (draw_context, depth, update_area, out_color_state, out_depth);
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-14 09:46:31 +00:00
}
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
typedef struct {
GArray *array;
guint committed;
} attribs_t;
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static void
attribs_init (attribs_t *attribs,
guint reserved)
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-14 09:46:31 +00:00
{
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
attribs->array = g_array_sized_new (TRUE, FALSE, sizeof (int), reserved);
attribs->committed = 0;
}
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static void
attribs_commit (attribs_t *attribs)
{
g_assert_true (attribs->array->len % 2 == 0);
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
attribs->committed = attribs->array->len;
}
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static void
attribs_reset (attribs_t *attribs)
{
g_array_set_size (attribs->array, attribs->committed);
}
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static void
attribs_add_bulk (attribs_t *attribs,
const int *array,
int n_elements)
{
g_assert (n_elements >= 0);
g_assert_true (n_elements % 2 == 0);
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
g_array_append_vals (attribs->array, array, n_elements);
}
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static void
attribs_add (attribs_t *attribs,
int key,
int value)
{
int array[2] = {key, value};
attribs_add_bulk (attribs, array, G_N_ELEMENTS (array));
}
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static bool
attribs_remove_last (attribs_t *attribs)
{
if (attribs->array->len > attribs->committed)
{
g_array_set_size (attribs->array, attribs->array->len - 1);
return true;
}
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
return false;
}
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static const int *
attribs_data (attribs_t *attribs)
{
return (const int *) attribs->array->data;
}
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static void
attribs_fini (attribs_t *attribs)
{
g_array_free (attribs->array, TRUE);
}
gdkglcontext-win32-wgl.c: Always request alpha bits ...when we are using wglChoosePixelFormatARHB(). This ensures that we hvae a HDC with a pixel format that will really support alpha bits, as we did for the traditional ChoosePixelFormat(). Thanks to Patrick Zacharias for testing and pointing things out.
2023-05-09 10:10:34 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
#define attribs_add_static_array(attribs, array) \
do attribs_add_bulk (attribs, array, G_N_ELEMENTS (array)); while (0)
WGL: Request that no depth, stencil and accum buffers be created Unspecified attributes are not interpreted as "leave this feature out", rather as "pick a default value". For depth, stencil and accum bits the defaults may be different than 0. For example, with AMD drivers we get: * WGL_DEPTH_BITS_ARB: 32 * WGL_STENCIL_BITS_ARB: 8 * WGL_ACCUM_BITS_ARB: 0 Set the attributes to 0 as a hint that depth, stencil and accum buffers should not be created. The driver may still create them (matching criteria is "minimum" [1]), but that's outside of our control (and unlikely to happen). References: [1] - WGL_ARB_pixel_format specification https://registry.khronos.org/OpenGL/extensions/ARB/WGL_ARB_pixel_format.txt See #6401
2024-02-16 20:30:23 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static int
find_pixel_format_with_defined_swap_flag (HDC hdc,
int formats[],
UINT count)
{
for (UINT i = 0; i < count; i++)
{
int query = WGL_SWAP_METHOD_ARB;
int value = WGL_SWAP_UNDEFINED_ARB;
WGL: Request that no depth, stencil and accum buffers be created Unspecified attributes are not interpreted as "leave this feature out", rather as "pick a default value". For depth, stencil and accum bits the defaults may be different than 0. For example, with AMD drivers we get: * WGL_DEPTH_BITS_ARB: 32 * WGL_STENCIL_BITS_ARB: 8 * WGL_ACCUM_BITS_ARB: 0 Set the attributes to 0 as a hint that depth, stencil and accum buffers should not be created. The driver may still create them (matching criteria is "minimum" [1]), but that's outside of our control (and unlikely to happen). References: [1] - WGL_ARB_pixel_format specification https://registry.khronos.org/OpenGL/extensions/ARB/WGL_ARB_pixel_format.txt See #6401
2024-02-16 20:30:23 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
SetLastError (0);
if (!wglGetPixelFormatAttribivARB (hdc, formats[i], 0, 1, &query, &value))
Win32 GL: Also force not to use depth/stencil/accum bits on legacy contexts For completeness' sake, also specifiy in the PIXELFORMATDESCRIPTOR to use no depth, stencil and accum bits to initializing WGL when we can't (yet) use wglChoosePixelFormatARB(), as we must always fist have a base legacy WGL context using ChoosePixelFormat() before we can use that to use wglChoosePixelFormatARB(), or if wglChoosePixelFormatARB() is somehow not available for us. Some drivers, however, enforces enabling depth buffers, so if we can't acquire a pixel format that disables depth buffers, retry acquiring one with that, which sadly is not optimal but we must make do. Attempts to complete fix for issue #6401.
2024-02-17 01:17:34 +00:00
{
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
WIN32_API_FAILED ("wglGetPixelFormatAttribivARB");
continue;
Win32 GL: Also force not to use depth/stencil/accum bits on legacy contexts For completeness' sake, also specifiy in the PIXELFORMATDESCRIPTOR to use no depth, stencil and accum bits to initializing WGL when we can't (yet) use wglChoosePixelFormatARB(), as we must always fist have a base legacy WGL context using ChoosePixelFormat() before we can use that to use wglChoosePixelFormatARB(), or if wglChoosePixelFormatARB() is somehow not available for us. Some drivers, however, enforces enabling depth buffers, so if we can't acquire a pixel format that disables depth buffers, retry acquiring one with that, which sadly is not optimal but we must make do. Attempts to complete fix for issue #6401.
2024-02-17 01:17:34 +00:00
}
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
if (value != WGL_SWAP_UNDEFINED_ARB)
return formats[i];
}
return 0;
}
static int
choose_pixel_format_arb_attribs (HDC hdc)
{
const int attribs_base[] = {
WGL_DRAW_TO_WINDOW_ARB,
GL_TRUE,
WGL_SUPPORT_OPENGL_ARB,
GL_TRUE,
WGL_DOUBLE_BUFFER_ARB,
GL_TRUE,
WGL_ACCELERATION_ARB,
WGL_FULL_ACCELERATION_ARB,
WGL_PIXEL_TYPE_ARB,
WGL_TYPE_RGBA_ARB,
WGL_COLOR_BITS_ARB,
32,
WGL_ALPHA_BITS_ARB,
8,
};
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
const int attribs_ancillary_buffers[] = {
WGL_STENCIL_BITS_ARB,
0,
WGL_ACCUM_BITS_ARB,
0,
WGL_DEPTH_BITS_ARB,
0,
};
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
attribs_t attribs;
int formats[4];
UINT count = 0;
int format = 0;
int saved = 0;
#define EXT_CALL(api, args) \
do { \
memset (formats, 0, sizeof (formats)); \
count = G_N_ELEMENTS (formats); \
\
if (!api args || count > G_N_ELEMENTS (formats)) \
{ \
count = 0; \
} \
} \
while (0)
const guint reserved = G_N_ELEMENTS (attribs_base) +
G_N_ELEMENTS (attribs_ancillary_buffers) +
1;
attribs_init (&attribs, reserved);
attribs_add_static_array (&attribs, attribs_base);
attribs_commit (&attribs);
attribs_add_static_array (&attribs, attribs_ancillary_buffers);
do
{
EXT_CALL (wglChoosePixelFormatARB, (hdc, attribs_data (&attribs), NULL,
G_N_ELEMENTS (formats), formats,
&count));
}
while (count == 0 && attribs_remove_last (&attribs));
if (count == 0)
goto done;
attribs_commit (&attribs);
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
/* That's an usable pixel format, save it */
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
saved = formats[0];
/* Do we have a defined swap method? */
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
format = find_pixel_format_with_defined_swap_flag (hdc, formats, count);
if (format > 0)
goto done;
/* Nope, but we can try to ask for it explicitly */
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
const int swap_methods[] = {
WGL_SWAP_EXCHANGE_ARB,
WGL_SWAP_COPY_ARB,
};
for (size_t i = 0; i < G_N_ELEMENTS (swap_methods); i++)
{
attribs_add (&attribs, WGL_SWAP_METHOD_ARB, swap_methods[i]);
EXT_CALL (wglChoosePixelFormatARB, (hdc, attribs_data (&attribs), NULL,
G_N_ELEMENTS (formats), formats,
&count));
format = find_pixel_format_with_defined_swap_flag (hdc, formats, count);
if (format > 0)
goto done;
attribs_reset (&attribs);
}
done:
attribs_fini (&attribs);
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-14 09:46:31 +00:00
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
if (format == 0)
return saved;
return format;
#undef EXT_CALL
}
WGL: Search pixel format with defined swap method (opengl32) We want to get PFD_SWAP flags as that's required to enable incremental rendering. However, as documented on MSDN, ChoosePixelFormat ignores PFD_SWAP flags. We may get PFD_SWAP flags or not depending on the way the OpenGL driver orders its pixel formats. While PFD_SWAP flags are very important for GUI toolkits, they are best avoided by games, as most games render the scene in its entirety on each frame. Drivers optimized for games tend to order pixel formats with no PFD_SWAP flags first. Se we implement our own method to select the best pixel format. We check for usable pixel formats and assign penalties for each one, until we find a format with 0 penalty or the sequence ends. Then the best pixel format is selected.
2024-07-23 14:06:52 +00:00
static int
get_distance (PIXELFORMATDESCRIPTOR *pfd)
{
const DWORD swap_flags = PFD_SWAP_COPY | PFD_SWAP_EXCHANGE;
int is_double_buffered = (pfd->dwFlags & PFD_DOUBLEBUFFER) != 0;
int is_swap_defined = (pfd->dwFlags & swap_flags) != 0;
int is_mono = (pfd->dwFlags & PFD_STEREO) == 0;
int ancillary_bits = pfd->cStencilBits + pfd->cDepthBits + pfd->cAccumBits;
int quality_distance = !is_double_buffered * 1000;
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
int performance_distance = !is_swap_defined * 200;
WGL: Search pixel format with defined swap method (opengl32) We want to get PFD_SWAP flags as that's required to enable incremental rendering. However, as documented on MSDN, ChoosePixelFormat ignores PFD_SWAP flags. We may get PFD_SWAP flags or not depending on the way the OpenGL driver orders its pixel formats. While PFD_SWAP flags are very important for GUI toolkits, they are best avoided by games, as most games render the scene in its entirety on each frame. Drivers optimized for games tend to order pixel formats with no PFD_SWAP flags first. Se we implement our own method to select the best pixel format. We check for usable pixel formats and assign penalties for each one, until we find a format with 0 penalty or the sequence ends. Then the best pixel format is selected.
2024-07-23 14:06:52 +00:00
int memory_distance = !is_mono + ancillary_bits;
return quality_distance +
performance_distance +
memory_distance;
}
/* ChoosePixelFormat ignored some fields and flags, which makes it
* less useful for GTK. In particular, it ignores the PFD_SWAP flags,
* which are very important for GUI toolkits. Here we implement an
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
* analog function which is tied to the needs of GTK.
*
* Note that ChoosePixelFormat is not implemented by the ICD, it's
* implemented in OpenGL32.DLL (though the driver can influence the
* outcome by ordering pixel formats in specific ways.
*/
WGL: Search pixel format with defined swap method (opengl32) We want to get PFD_SWAP flags as that's required to enable incremental rendering. However, as documented on MSDN, ChoosePixelFormat ignores PFD_SWAP flags. We may get PFD_SWAP flags or not depending on the way the OpenGL driver orders its pixel formats. While PFD_SWAP flags are very important for GUI toolkits, they are best avoided by games, as most games render the scene in its entirety on each frame. Drivers optimized for games tend to order pixel formats with no PFD_SWAP flags first. Se we implement our own method to select the best pixel format. We check for usable pixel formats and assign penalties for each one, until we find a format with 0 penalty or the sequence ends. Then the best pixel format is selected.
2024-07-23 14:06:52 +00:00
static int
choose_pixel_format_opengl32 (HDC hdc)
{
const DWORD skip_flags = PFD_GENERIC_FORMAT |
PFD_GENERIC_ACCELERATED;
const DWORD required_flags = PFD_DRAW_TO_WINDOW |
PFD_SUPPORT_OPENGL;
struct {
int index;
int distance;
} best = { 0, 1, }, current;
PIXELFORMATDESCRIPTOR pfd;
int count = DescribePixelFormat (hdc, 1, sizeof (pfd), NULL);
for (current.index = 1; current.index <= count && best.distance > 0; current.index++)
{
if (DescribePixelFormat (hdc, current.index, sizeof (pfd), &pfd) <= 0)
{
WIN32_API_FAILED ("DescribePixelFormat");
return 0;
}
if ((pfd.dwFlags & skip_flags) != 0 ||
(pfd.dwFlags & required_flags) != required_flags)
continue;
if (pfd.iPixelType != PFD_TYPE_RGBA ||
(pfd.cRedBits != 8 || pfd.cGreenBits != 8 ||
pfd.cBlueBits != 8 || pfd.cAlphaBits != 8))
continue;
current.distance = get_distance (&pfd);
if (best.index == 0 || current.distance < best.distance)
best = current;
}
return best.index;
}
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
static int
get_wgl_pfd (HDC hdc,
PIXELFORMATDESCRIPTOR *pfd,
GdkWin32Display *display_win32)
{
int best_pf = 0;
if (display_win32->hasWglARBPixelFormat)
{
/* Save up the HDC and HGLRC that we are currently using, to restore back to it when we are done here */
HDC hdc_current = wglGetCurrentDC ();
HGLRC hglrc_current = wglGetCurrentContext ();
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-14 09:46:31 +00:00
if (!wglMakeCurrent (display_win32->dummy_context_wgl.hdc,
display_win32->dummy_context_wgl.hglrc))
{
wglMakeCurrent (hdc_current, hglrc_current);
return 0;
}
WGL: Search pixel format with defined swap method (arb) Getting a defined swap method is necessary to enable incremental rendering. We cannot just add a swap method attribute since exchange is generally preferred, but is not always available. Here we try to infer what the driver prefers, then ask for exchange or copy, in sequence.
2024-07-23 13:36:17 +00:00
best_pf = choose_pixel_format_arb_attribs (hdc);
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-14 09:46:31 +00:00
/* Go back to the HDC that we were using, since we are done with the dummy HDC and GL Context */
wglMakeCurrent (hdc_current, hglrc_current);
}
else
{
WGL: Search pixel format with defined swap method (opengl32) We want to get PFD_SWAP flags as that's required to enable incremental rendering. However, as documented on MSDN, ChoosePixelFormat ignores PFD_SWAP flags. We may get PFD_SWAP flags or not depending on the way the OpenGL driver orders its pixel formats. While PFD_SWAP flags are very important for GUI toolkits, they are best avoided by games, as most games render the scene in its entirety on each frame. Drivers optimized for games tend to order pixel formats with no PFD_SWAP flags first. Se we implement our own method to select the best pixel format. We check for usable pixel formats and assign penalties for each one, until we find a format with 0 penalty or the sequence ends. Then the best pixel format is selected.
2024-07-23 14:06:52 +00:00
best_pf = choose_pixel_format_opengl32 (hdc);
if (best_pf > 0)
DescribePixelFormat (hdc, best_pf, sizeof (PIXELFORMATDESCRIPTOR), pfd);
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-14 09:46:31 +00:00
}
return best_pf;
}
/* in WGL, for many OpenGL items, we need a dummy WGL context, so create
* one and cache it for later use
*/
static int
gdk_init_dummy_wgl_context (GdkWin32Display *display_win32)
{
PIXELFORMATDESCRIPTOR pfd;
gboolean set_pixel_format_result = FALSE;
int best_idx = 0;
memset (&pfd, 0, sizeof (PIXELFORMATDESCRIPTOR));
Win32 GL: Also force not to use depth/stencil/accum bits on legacy contexts For completeness' sake, also specifiy in the PIXELFORMATDESCRIPTOR to use no depth, stencil and accum bits to initializing WGL when we can't (yet) use wglChoosePixelFormatARB(), as we must always fist have a base legacy WGL context using ChoosePixelFormat() before we can use that to use wglChoosePixelFormatARB(), or if wglChoosePixelFormatARB() is somehow not available for us. Some drivers, however, enforces enabling depth buffers, so if we can't acquire a pixel format that disables depth buffers, retry acquiring one with that, which sadly is not optimal but we must make do. Attempts to complete fix for issue #6401.
2024-02-17 01:17:34 +00:00
best_idx = get_wgl_pfd (display_win32->dummy_context_wgl.hdc, &pfd, display_win32);
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-14 09:46:31 +00:00
if (best_idx != 0)
set_pixel_format_result = SetPixelFormat (display_win32->dummy_context_wgl.hdc,
best_idx,
&pfd);
if (best_idx == 0 || !set_pixel_format_result)
return 0;
display_win32->dummy_context_wgl.hglrc =
wglCreateContext (display_win32->dummy_context_wgl.hdc);
if (display_win32->dummy_context_wgl.hglrc == NULL)
return 0;
return best_idx;
}
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
/*
* Use a dummy HWND to init GL, sadly we can't just use the
* HWND that we use for notifications as we may only call
* SetPixelFormat() on an HDC once, and that notification HWND
* uses the CS_OWNDC style meaning that even if we were to call
* DeleteDC() on it, we would get the exact same HDC when we call
* GetDC() on it later, meaning SetPixelFormat() cannot be used
* again on the HDC that we acquire from the notification HWND.
*/
static HWND
create_dummy_gl_window (void)
{
WNDCLASS wclass = { 0, };
ATOM klass;
win32/wgl: Initialize hwnd to NULL Otherwise there's a valid code path that may return it uninitialized.
2024-05-03 12:51:46 +00:00
HWND hwnd = NULL;
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
Windows: Build with UNICODE Build with UNICODE (and _UNICODE) defined when targeting Windows.
2024-05-06 12:27:33 +00:00
wclass.lpszClassName = L"GdkGLDummyWindow";
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
wclass.lpfnWndProc = DefWindowProc;
Do not keep HINSTANCE variables around Use &__ImageBase for the GTK DLL and GetModuleHandle (NULL) for the application module. Then remove DllMain as it's not necessary anymore. References: [1] Accessing the current module's HINSTANCE from a static library: https://devblogs.microsoft.com/oldnewthing/20041025-00/?p=37483
2023-03-23 15:27:17 +00:00
wclass.hInstance = this_module ();
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
wclass.style = CS_OWNDC;
klass = RegisterClass (&wclass);
if (klass)
{
hwnd = CreateWindow (MAKEINTRESOURCE (klass),
NULL, WS_POPUP,
0, 0, 0, 0, NULL, NULL,
Do not keep HINSTANCE variables around Use &__ImageBase for the GTK DLL and GetModuleHandle (NULL) for the application module. Then remove DllMain as it's not necessary anymore. References: [1] Accessing the current module's HINSTANCE from a static library: https://devblogs.microsoft.com/oldnewthing/20041025-00/?p=37483
2023-03-23 15:27:17 +00:00
this_module (), NULL);
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
if (!hwnd)
{
Do not keep HINSTANCE variables around Use &__ImageBase for the GTK DLL and GetModuleHandle (NULL) for the application module. Then remove DllMain as it's not necessary anymore. References: [1] Accessing the current module's HINSTANCE from a static library: https://devblogs.microsoft.com/oldnewthing/20041025-00/?p=37483
2023-03-23 15:27:17 +00:00
UnregisterClass (MAKEINTRESOURCE (klass), this_module ());
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
}
}
return hwnd;
}
wgl: Create context during WGL initialization This way, we can realize it and either print success information about it or return NULL if that fails. This makes it more likely that we fail early, which means we can then initialize EGL.
2023-04-26 04:16:37 +00:00
GdkGLContext *
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-14 09:46:31 +00:00
gdk_win32_display_init_wgl (GdkDisplay *display,
GError **error)
{
int best_idx = 0;
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (display);
wgl: Create context during WGL initialization This way, we can realize it and either print success information about it or return NULL if that fails. This makes it more likely that we fail early, which means we can then initialize EGL.
2023-04-26 04:16:37 +00:00
GdkGLContext *context;
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-14 09:46:31 +00:00
HDC hdc;
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-23 23:47:03 +00:00
if (!gdk_gl_backend_can_be_used (GDK_GL_WGL, error))
wgl: Create context during WGL initialization This way, we can realize it and either print success information about it or return NULL if that fails. This makes it more likely that we fail early, which means we can then initialize EGL.
2023-04-26 04:16:37 +00:00
return NULL;
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-23 23:47:03 +00:00
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-14 09:46:31 +00:00
/* acquire and cache dummy Window (HWND & HDC) and
* dummy GL Context, it is used to query functions
* and used for other stuff as well
*/
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
if (display_win32->dummy_context_wgl.hdc == NULL)
{
display_win32->dummy_context_wgl.hwnd = create_dummy_gl_window ();
if (display_win32->dummy_context_wgl.hwnd != NULL)
display_win32->dummy_context_wgl.hdc = GetDC (display_win32->dummy_context_wgl.hwnd);
}
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-14 09:46:31 +00:00
best_idx = gdk_init_dummy_wgl_context (display_win32);
hdc = display_win32->dummy_context_wgl.hdc;
if (best_idx == 0 ||
!wglMakeCurrent (hdc, display_win32->dummy_context_wgl.hglrc))
{
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 07:13:38 +00:00
if (display_win32->dummy_context_wgl.hglrc != NULL)
wglDeleteContext (display_win32->dummy_context_wgl.hglrc);
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-14 09:46:31 +00:00
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("No GL implementation is available"));
wgl: Create context during WGL initialization This way, we can realize it and either print success information about it or return NULL if that fails. This makes it more likely that we fail early, which means we can then initialize EGL.
2023-04-26 04:16:37 +00:00
return NULL;
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-14 09:46:31 +00:00
}
display_win32->hasWglARBCreateContext =
epoxy_has_wgl_extension (hdc, "WGL_ARB_create_context");
display_win32->hasWglEXTSwapControl =
epoxy_has_wgl_extension (hdc, "WGL_EXT_swap_control");
display_win32->hasWglOMLSyncControl =
epoxy_has_wgl_extension (hdc, "WGL_OML_sync_control");
display_win32->hasWglARBPixelFormat =
epoxy_has_wgl_extension (hdc, "WGL_ARB_pixel_format");
wgl: Create context during WGL initialization This way, we can realize it and either print success information about it or return NULL if that fails. This makes it more likely that we fail early, which means we can then initialize EGL.
2023-04-26 04:16:37 +00:00
context = g_object_new (GDK_TYPE_WIN32_GL_CONTEXT_WGL,
"display", display,
NULL);
if (!gdk_gl_context_realize (context, error))
{
g_object_unref (context);
return NULL;
}
win32: Get rid of display->gl_version We can just query the display's GL context. And it's not used otherwise anymore.
2023-04-26 03:54:45 +00:00
wgl: Create context during WGL initialization This way, we can realize it and either print success information about it or return NULL if that fails. This makes it more likely that we fail early, which means we can then initialize EGL.
2023-04-26 04:16:37 +00:00
{
int major, minor;
gdk_gl_context_get_version (context, &major, &minor);
GDK_NOTE (OPENGL, g_print ("WGL API version %d.%d found\n"
" - Vendor: %s\n"
" - Checked extensions:\n"
"\t* WGL_ARB_pixel_format: %s\n"
"\t* WGL_ARB_create_context: %s\n"
"\t* WGL_EXT_swap_control: %s\n"
win32: Turn off multisampling We know we draw beautiful Windows, but drawing them once is totally enough.
2023-04-29 05:00:45 +00:00
"\t* WGL_OML_sync_control: %s\n",
wgl: Create context during WGL initialization This way, we can realize it and either print success information about it or return NULL if that fails. This makes it more likely that we fail early, which means we can then initialize EGL.
2023-04-26 04:16:37 +00:00
major, minor,
glGetString (GL_VENDOR),
display_win32->hasWglARBPixelFormat ? "yes" : "no",
display_win32->hasWglARBCreateContext ? "yes" : "no",
display_win32->hasWglEXTSwapControl ? "yes" : "no",
win32: Turn off multisampling We know we draw beautiful Windows, but drawing them once is totally enough.
2023-04-29 05:00:45 +00:00
display_win32->hasWglOMLSyncControl ? "yes" : "no"));
wgl: Create context during WGL initialization This way, we can realize it and either print success information about it or return NULL if that fails. This makes it more likely that we fail early, which means we can then initialize EGL.
2023-04-26 04:16:37 +00:00
}
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-14 09:46:31 +00:00
wglMakeCurrent (NULL, NULL);
wgl: Create context during WGL initialization This way, we can realize it and either print success information about it or return NULL if that fails. This makes it more likely that we fail early, which means we can then initialize EGL.
2023-04-26 04:16:37 +00:00
return context;
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-14 09:46:31 +00:00
}
/* Setup the legacy context after creating it */
static gboolean
wgl: Improve error messages when GL init fails In particular, we want to get the GL version, when the Windows box/VM has an unsuitable GL implementation. This is somewhat helpful in analyzing failures to bring up GL on machines where users claim GL does work.
2023-04-26 16:08:59 +00:00
ensure_legacy_wgl_context (HDC hdc,
HGLRC hglrc_legacy,
GdkGLContext *share,
GdkGLVersion *version,
GError **error)
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-14 09:46:31 +00:00
{
GdkWin32GLContextWGL *context_wgl;
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
GdkGLVersion legacy_version;
GDK_NOTE (OPENGL,
g_print ("Creating legacy WGL context (version:%d.%d)\n",
gdk_gl_version_get_major (version),
gdk_gl_version_get_minor (version)));
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-14 09:46:31 +00:00
if (!wglMakeCurrent (hdc, hglrc_legacy))
wgl: Improve error messages when GL init fails In particular, we want to get the GL version, when the Windows box/VM has an unsuitable GL implementation. This is somewhat helpful in analyzing failures to bring up GL on machines where users claim GL does work.
2023-04-26 16:08:59 +00:00
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("Unable to create a GL context"));
return FALSE;
}
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-14 09:46:31 +00:00
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
gdk_gl_version_init_epoxy (&legacy_version);
if (!gdk_gl_version_greater_equal (&legacy_version, version))
wgl: Improve error messages when GL init fails In particular, we want to get the GL version, when the Windows box/VM has an unsuitable GL implementation. This is somewhat helpful in analyzing failures to bring up GL on machines where users claim GL does work.
2023-04-26 16:08:59 +00:00
{
g_set_error (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("WGL version %d.%d is too low, need at least %d.%d"),
gdk_gl_version_get_major (&legacy_version),
gdk_gl_version_get_minor (&legacy_version),
gdk_gl_version_get_major (version),
gdk_gl_version_get_minor (version));
return FALSE;
}
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
*version = legacy_version;
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-14 09:46:31 +00:00
if (share != NULL)
{
context_wgl = GDK_WIN32_GL_CONTEXT_WGL (share);
wgl: Improve error messages when GL init fails In particular, we want to get the GL version, when the Windows box/VM has an unsuitable GL implementation. This is somewhat helpful in analyzing failures to bring up GL on machines where users claim GL does work.
2023-04-26 16:08:59 +00:00
if (!wglShareLists (hglrc_legacy, context_wgl->wgl_context))
{
g_set_error (error, GDK_GL_ERROR,
GDK_GL_ERROR_UNSUPPORTED_PROFILE,
_("GL implementation cannot share GL contexts"));
return FALSE;
}
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-14 09:46:31 +00:00
}
return TRUE;
}
static HGLRC
create_wgl_context_with_attribs (HDC hdc,
GdkGLContext *share,
int flags,
win32: Make sure highest possible GL version is created Mirror EGL here.
2023-04-25 19:55:16 +00:00
gboolean is_legacy,
GdkGLVersion *version)
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-14 09:46:31 +00:00
{
HGLRC hglrc;
GdkWin32GLContextWGL *context_wgl;
win32: Make sure highest possible GL version is created Mirror EGL here.
2023-04-25 19:55:16 +00:00
const GdkGLVersion *supported_versions = gdk_gl_versions_get_for_api (GDK_GL_API_GL);
guint i;
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-14 09:46:31 +00:00
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
GDK_NOTE (OPENGL,
g_print ("Creating %s WGL context (version:%d.%d, debug:%s, forward:%s)\n",
is_legacy ? "core" : "compat",
gdk_gl_version_get_major (version),
gdk_gl_version_get_minor (version),
(flags & WGL_CONTEXT_DEBUG_BIT_ARB) ? "yes" : "no",
(flags & WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB) ? "yes" : "no"));
win32: Make sure highest possible GL version is created Mirror EGL here.
2023-04-25 19:55:16 +00:00
for (i = 0; gdk_gl_version_greater_equal (&supported_versions[i], version); i++)
{
/* if we have wglCreateContextAttribsARB(), create a
* context with the compatibility profile if a legacy
* context is requested, or when we go into fallback mode
*/
int profile = is_legacy ? WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB :
WGL_CONTEXT_CORE_PROFILE_BIT_ARB;
int attribs[] = {
WGL_CONTEXT_PROFILE_MASK_ARB, profile,
WGL_CONTEXT_MAJOR_VERSION_ARB, gdk_gl_version_get_major (&supported_versions[i]),
WGL_CONTEXT_MINOR_VERSION_ARB, gdk_gl_version_get_minor (&supported_versions[i]),
WGL_CONTEXT_FLAGS_ARB, flags,
0
};
if (share != NULL)
context_wgl = GDK_WIN32_GL_CONTEXT_WGL (share);
hglrc = wglCreateContextAttribsARB (hdc,
share != NULL ? context_wgl->wgl_context : NULL,
attribs);
if (hglrc)
{
*version = supported_versions[i];
return hglrc;
}
}
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-14 09:46:31 +00:00
win32: Make sure highest possible GL version is created Mirror EGL here.
2023-04-25 19:55:16 +00:00
return NULL;
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-14 09:46:31 +00:00
}
static HGLRC
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
create_base_wgl_context (GdkWin32Display *display_win32,
HDC hdc,
gboolean force_create_base_context,
gboolean *remove_base_context)
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-14 09:46:31 +00:00
{
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
HGLRC hglrc_base = NULL;
if (force_create_base_context || display_win32->dummy_context_wgl.hglrc == NULL)
{
hglrc_base = wglCreateContext (hdc);
if (hglrc_base == NULL)
return NULL;
*remove_base_context = !force_create_base_context;
}
else
hglrc_base = display_win32->dummy_context_wgl.hglrc;
return hglrc_base;
}
static HGLRC
create_wgl_context (GdkGLContext *context,
GdkWin32Display *display_win32,
HDC hdc,
GdkGLContext *share,
int flags,
gboolean legacy,
GError **error)
{
/* We need a legacy context for *all* cases, if no WGL contexts are created */
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
HGLRC hglrc_base, hglrc;
GdkGLVersion version;
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
gboolean remove_base_context = FALSE;
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-14 09:46:31 +00:00
/* Save up the HDC and HGLRC that we are currently using, to restore back to it when we are done here */
HDC hdc_current = wglGetCurrentDC ();
HGLRC hglrc_current = wglGetCurrentContext ();
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
hglrc = NULL;
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-14 09:46:31 +00:00
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
if (display_win32->hasWglARBCreateContext)
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
{
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
hglrc_base = create_base_wgl_context (display_win32,
hdc,
FALSE,
&remove_base_context);
if (hglrc_base == NULL || !wglMakeCurrent (hdc, hglrc_base))
{
g_clear_pointer (&hglrc_base, gdk_win32_private_wglDeleteContext);
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("Unable to create a GL context"));
return 0;
}
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
if (!legacy)
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-14 09:46:31 +00:00
{
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
gdk_gl_context_get_matching_version (context,
GDK_GL_API_GL,
FALSE,
&version);
hglrc = create_wgl_context_with_attribs (hdc,
share,
flags,
FALSE,
&version);
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-14 09:46:31 +00:00
}
if (hglrc == NULL)
{
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
legacy = TRUE;
gdk_gl_context_get_matching_version (context,
GDK_GL_API_GL,
TRUE,
&version);
hglrc = create_wgl_context_with_attribs (hdc,
share,
flags,
TRUE,
&version);
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-14 09:46:31 +00:00
}
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
}
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-14 09:46:31 +00:00
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
if (hglrc == NULL)
{
legacy = TRUE;
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
hglrc_base = create_base_wgl_context (display_win32,
hdc,
TRUE,
&remove_base_context);
if (hglrc_base == NULL || !wglMakeCurrent (hdc, hglrc_base))
{
g_clear_pointer (&hglrc_base, gdk_win32_private_wglDeleteContext);
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("Unable to create a GL context"));
return 0;
}
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
gdk_gl_context_get_matching_version (context,
GDK_GL_API_GL,
TRUE,
&version);
wgl: Improve error messages when GL init fails In particular, we want to get the GL version, when the Windows box/VM has an unsuitable GL implementation. This is somewhat helpful in analyzing failures to bring up GL on machines where users claim GL does work.
2023-04-26 16:08:59 +00:00
if (ensure_legacy_wgl_context (hdc, hglrc_base, share, &version, error))
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
hglrc = g_steal_pointer (&hglrc_base);
}
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-14 09:46:31 +00:00
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
if (hglrc)
{
gdk_gl_context_set_version (context, &version);
gdk_gl_context_set_is_legacy (context, legacy);
}
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-14 09:46:31 +00:00
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
if (remove_base_context)
g_clear_pointer (&hglrc_base, gdk_win32_private_wglDeleteContext);
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-14 09:46:31 +00:00
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
wglMakeCurrent (hdc_current, hglrc_current);
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-14 09:46:31 +00:00
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
return hglrc;
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-14 09:46:31 +00:00
}
static gboolean
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
set_wgl_pixformat_for_hdc (GdkWin32Display *display_win32,
HDC *hdc,
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-14 09:46:31 +00:00
int *best_idx,
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
gboolean *recreate_dummy_context)
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-14 09:46:31 +00:00
{
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
gboolean skip_acquire = FALSE;
gboolean set_pixel_format_result = FALSE;
WGL: Initialize PIXELFORMATDESCRIPTOR structure
2024-02-17 09:19:09 +00:00
PIXELFORMATDESCRIPTOR pfd = {0};
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-14 09:46:31 +00:00
/* one is only allowed to call SetPixelFormat(), and so ChoosePixelFormat()
* one single time per window HDC
*/
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
GDK_NOTE (OPENGL, g_print ("requesting pixel format...\n"));
*best_idx = get_wgl_pfd (*hdc, &pfd, display_win32);
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-14 09:46:31 +00:00
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
if (display_win32->dummy_context_wgl.hwnd != NULL)
{
/*
* Ditch the initial dummy HDC, HGLRC and HWND used to initialize WGL,
* we want to ensure that the HDC of the notification HWND that we will
* also use for our new dummy HDC will have the correct pixel format set
*/
wglDeleteContext (display_win32->dummy_context_wgl.hglrc);
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
display_win32->dummy_context_wgl.hglrc = NULL;
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
display_win32->dummy_context_wgl.hdc = GetDC (display_win32->hwnd);
*hdc = display_win32->dummy_context_wgl.hdc;
*recreate_dummy_context = TRUE;
DestroyWindow (display_win32->dummy_context_wgl.hwnd);
display_win32->dummy_context_wgl.hwnd = NULL;
}
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-14 09:46:31 +00:00
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
if (GetPixelFormat (*hdc) != 0)
{
skip_acquire = TRUE;
set_pixel_format_result = TRUE;
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-14 09:46:31 +00:00
}
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
else if (*best_idx != 0)
set_pixel_format_result = SetPixelFormat (*hdc, *best_idx, &pfd);
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-14 09:46:31 +00:00
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
/* ChoosePixelFormat() or SetPixelFormat() failed, bail out */
if (*best_idx == 0 || !set_pixel_format_result)
return FALSE;
GDK_NOTE (OPENGL, g_print ("%s""requested and set pixel format: %d\n", skip_acquire ? "already " : "", *best_idx));
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-14 09:46:31 +00:00
return TRUE;
}
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-07 20:10:39 +00:00
static GdkGLAPI
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-14 09:46:31 +00:00
gdk_win32_gl_context_wgl_realize (GdkGLContext *context,
GError **error)
{
GdkWin32GLContextWGL *context_wgl = GDK_WIN32_GL_CONTEXT_WGL (context);
gboolean debug_bit, compat_bit, legacy_bit;
/* request flags and specific versions for core (3.2+) WGL context */
int flags = 0;
HGLRC hglrc;
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
int pixel_format = 0;
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-14 09:46:31 +00:00
HDC hdc;
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
gboolean recreate_dummy_context = FALSE;
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-14 09:46:31 +00:00
GdkSurface *surface = gdk_gl_context_get_surface (context);
GdkDisplay *display = gdk_gl_context_get_display (context);
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (display);
GdkGLContext *share = gdk_display_get_gl_context (display);
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-07 20:10:39 +00:00
if (!gdk_gl_context_is_api_allowed (context, GDK_GL_API_GL, error))
return 0;
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-14 09:46:31 +00:00
debug_bit = gdk_gl_context_get_debug_enabled (context);
compat_bit = gdk_gl_context_get_forward_compatible (context);
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-17 10:14:30 +00:00
/*
win32: Make sure highest possible GL version is created Mirror EGL here.
2023-04-25 19:55:16 +00:00
* A legacy context cannot be shared with core profile ones, so this means we
* must stick to a legacy context if the shared context is a legacy context
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-17 10:14:30 +00:00
*/
Drop the gl-legacy debug value The consensus is that we can do without this.
2023-11-18 23:58:37 +00:00
legacy_bit = share != NULL && gdk_gl_context_is_legacy (share);
win32: Make sure highest possible GL version is created Mirror EGL here.
2023-04-25 19:55:16 +00:00
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-14 09:46:31 +00:00
if (surface != NULL)
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-19 02:32:28 +00:00
hdc = GDK_WIN32_SURFACE (surface)->hdc;
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-14 09:46:31 +00:00
else
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-19 02:32:28 +00:00
hdc = display_win32->dummy_context_wgl.hdc;
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-14 09:46:31 +00:00
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
if (!set_wgl_pixformat_for_hdc (display_win32,
&hdc,
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-14 09:46:31 +00:00
&pixel_format,
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
&recreate_dummy_context))
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-14 09:46:31 +00:00
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_UNSUPPORTED_FORMAT,
_("No available configurations for the given pixel format"));
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-07 20:10:39 +00:00
return 0;
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-14 09:46:31 +00:00
}
/* if there isn't wglCreateContextAttribsARB() on WGL, use a legacy context */
if (!legacy_bit)
legacy_bit = !display_win32->hasWglARBCreateContext;
if (debug_bit)
flags |= WGL_CONTEXT_DEBUG_BIT_ARB;
if (compat_bit)
flags |= WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB;
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
hglrc = create_wgl_context (context,
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
display_win32,
win32: Refactor context creation This refactor achieves the following: * check GL version against proper matching context version In particular, for legacy contexts, we now actually check * make sure the actual version is set, even for legacy contexts * make sure set_is_legacy() is set properly
2023-04-26 02:17:32 +00:00
hdc,
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-14 09:46:31 +00:00
share,
flags,
wgl: Improve error messages when GL init fails In particular, we want to get the GL version, when the Windows box/VM has an unsuitable GL implementation. This is somewhat helpful in analyzing failures to bring up GL on machines where users claim GL does work.
2023-04-26 16:08:59 +00:00
legacy_bit,
error);
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
if (recreate_dummy_context)
{
display_win32->dummy_context_wgl.hglrc =
create_wgl_context (context,
GDK/Win32: Use dummy WGL contexts more ... for creating the actual WGL contexts, so that we can cut down on the number of times where we need to create the base, legacy WGL contexts in order to create the WGL contexts with attributes. We could just use the dummy context that we have to make it current to create the needed WGL contexts.
2023-05-04 16:09:43 +00:00
display_win32,
gdkglcontext-win32-wgl.c: Fix using wglChoosePixelFormatARB() If we are querying the best supported pixel format for our HDC via wglChoosePixelFormatARB() (i.e. we have the WGL_ARB_pixel_format extension), it may return a pixel format that is different from the pixel format that we used for the dummy context that we have setup, in order to, well, run wglChoosePixelFormatARB(), which sadly requires a WGL context (HGLRC) to be current in order to use it, which means the dummy HDC already has a pixel format that has been set (notice that each HDC is only allowed to have its pixel format to be set *once*). This is notably the case on Intel display drivers. Since we are emulating surfaceless GL contexts, we are using the dummy GL context (and thus dummy HDC that is derived from the notification HWND used in GdkWin32Display) for doing that, we would get into trouble if th actual HDC from the GdkWin32Surface has a different pixel format set. So, as a result, in order to fix this situation, we do the following: * Create yet another dummy HWND in order to grab the HDC to query for the capabilities the GL drivers support, and to call wglChoosePixelFormatARB() as appropriate (or ChoosePixelFormat()) for the final pixel format that we use. * Ditch the dummy GL context, HDC and HWND after obtaining the pixel format. * Then set the final pixel format that we obtained onto the HDC that is derived from the HWND used in GdkWin32Display for notifications, which will become our new dummy HDC. * Create a new dummy HGLRC for use with the new dummy HDC to emulate surfaceless GL support.
2023-05-03 09:58:54 +00:00
display_win32->dummy_context_wgl.hdc,
NULL,
flags,
legacy_bit,
error);
if (display_win32->dummy_context_wgl.hglrc == NULL)
{
if (hglrc != NULL)
{
wglDeleteContext (hglrc);
hglrc = NULL;
}
}
}
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-14 09:46:31 +00:00
if (hglrc == NULL)
wgl: Improve error messages when GL init fails In particular, we want to get the GL version, when the Windows box/VM has an unsuitable GL implementation. This is somewhat helpful in analyzing failures to bring up GL on machines where users claim GL does work.
2023-04-26 16:08:59 +00:00
return 0;
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-14 09:46:31 +00:00
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
context_wgl->wgl_context = hglrc;
HDC hdc_current = wglGetCurrentDC ();
HGLRC hglrc_current = wglGetCurrentContext ();
if (wglMakeCurrent (hdc, hglrc))
{
if (display_win32->hasWglARBPixelFormat)
{
/* wglChoosePixelFormatARB should match these attributes exactly
* as requested, according to the spec, but better check anyway */
int query_attribs[] = {
WGL_DOUBLE_BUFFER_ARB,
WGL_SWAP_METHOD_ARB,
};
int query_values[G_N_ELEMENTS (query_attribs)];
memset (query_values, 0, sizeof (query_values));
if (wglGetPixelFormatAttribivARB (hdc, pixel_format, 0, G_N_ELEMENTS (query_attribs), query_attribs, query_values))
{
context_wgl->double_buffered = (query_values[0] == GL_TRUE);
switch (query_values[1])
{
case WGL_SWAP_COPY_ARB:
context_wgl->swap_method = SWAP_METHOD_COPY;
break;
case WGL_SWAP_EXCHANGE_ARB:
context_wgl->swap_method = SWAP_METHOD_EXCHANGE;
break;
default:
context_wgl->swap_method = SWAP_METHOD_UNDEFINED;
break;
}
}
}
else
{
PIXELFORMATDESCRIPTOR pfd = {0};
if (DescribePixelFormat (hdc, pixel_format, sizeof (pfd), &pfd))
{
context_wgl->double_buffered = (pfd.dwFlags & PFD_DOUBLEBUFFER) != 0;
if (pfd.dwFlags & PFD_SWAP_COPY)
context_wgl->swap_method = SWAP_METHOD_COPY;
else if (pfd.dwFlags & PFD_SWAP_EXCHANGE)
context_wgl->swap_method = SWAP_METHOD_EXCHANGE;
else
context_wgl->swap_method = SWAP_METHOD_UNDEFINED;
}
}
}
wglMakeCurrent (hdc_current, hglrc_current);
if (context_wgl->swap_method == SWAP_METHOD_UNDEFINED)
g_message ("Unkwown swap method");
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-14 09:46:31 +00:00
GDK_NOTE (OPENGL,
g_print ("Created WGL context[%p], pixel_format=%d\n",
hglrc,
pixel_format));
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-07 20:10:39 +00:00
return GDK_GL_API_GL;
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-14 09:46:31 +00:00
}
static gboolean
gdk_win32_gl_context_wgl_clear_current (GdkGLContext *context)
{
GDK-Win32: Add wrapper functions for calling core wgl* functions We might be dealing with GL contexts from different threads, which have more gotchas when we are using libepoxy, so in case the function pointers for these are invalidated by wglMakeCurrent() calls outside of GTK/GDK, such as in GstGL, we want to use these functions that are directly linked to opengl32.dll provided by the system/ICD, by linking to opengl32.lib. This will ensure that we will indeed call the "correct" wgl* functions that we need. This should help fix issue #5685.
2023-03-24 03:08:26 +00:00
return gdk_win32_private_wglMakeCurrent (NULL, NULL);
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-14 09:46:31 +00:00
}
gdk: Add private GLContext::is_current() check ... and use this check in gdk_gl_context_make_current() and gdk_gl_context_get_current() to make sure the context really is still current. The context no longer being current can happen when external GL implementations make their own contexts current in the same threads GDK contexts are used in. And that can happen for example by WebKit. Theoretically, this should also allow external EGL code to run in X11 applications when GDK chooses to use GLX, but I didn't try it. Fixes #5392
2023-02-02 01:49:56 +00:00
static gboolean
gdk_win32_gl_context_wgl_is_current (GdkGLContext *context)
{
GdkWin32GLContextWGL *self = GDK_WIN32_GL_CONTEXT_WGL (context);
GDK-Win32: Add wrapper functions for calling core wgl* functions We might be dealing with GL contexts from different threads, which have more gotchas when we are using libepoxy, so in case the function pointers for these are invalidated by wglMakeCurrent() calls outside of GTK/GDK, such as in GstGL, we want to use these functions that are directly linked to opengl32.dll provided by the system/ICD, by linking to opengl32.lib. This will ensure that we will indeed call the "correct" wgl* functions that we need. This should help fix issue #5685.
2023-03-24 03:08:26 +00:00
return self->wgl_context == gdk_win32_private_wglGetCurrentContext ();
gdk: Add private GLContext::is_current() check ... and use this check in gdk_gl_context_make_current() and gdk_gl_context_get_current() to make sure the context really is still current. The context no longer being current can happen when external GL implementations make their own contexts current in the same threads GDK contexts are used in. And that can happen for example by WebKit. Theoretically, this should also allow external EGL code to run in X11 applications when GDK chooses to use GLX, but I didn't try it. Fixes #5392
2023-02-02 01:49:56 +00:00
}
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-14 09:46:31 +00:00
static gboolean
gdk_win32_gl_context_wgl_make_current (GdkGLContext *context,
gboolean surfaceless)
{
GdkWin32GLContextWGL *context_wgl = GDK_WIN32_GL_CONTEXT_WGL (context);
GdkDisplay *display = gdk_gl_context_get_display (context);
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (display);
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-19 02:32:28 +00:00
GdkSurface *surface = gdk_gl_context_get_surface (context);
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-14 09:46:31 +00:00
HDC hdc;
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-19 02:32:28 +00:00
if (surfaceless || surface == NULL)
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-14 09:46:31 +00:00
hdc = display_win32->dummy_context_wgl.hdc;
else
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-19 02:32:28 +00:00
hdc = GDK_WIN32_SURFACE (surface)->hdc;
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-14 09:46:31 +00:00
GDK-Win32: Add wrapper functions for calling core wgl* functions We might be dealing with GL contexts from different threads, which have more gotchas when we are using libepoxy, so in case the function pointers for these are invalidated by wglMakeCurrent() calls outside of GTK/GDK, such as in GstGL, we want to use these functions that are directly linked to opengl32.dll provided by the system/ICD, by linking to opengl32.lib. This will ensure that we will indeed call the "correct" wgl* functions that we need. This should help fix issue #5685.
2023-03-24 03:08:26 +00:00
if (!gdk_win32_private_wglMakeCurrent (hdc, context_wgl->wgl_context))
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-14 09:46:31 +00:00
return FALSE;
if (!surfaceless && display_win32->hasWglEXTSwapControl)
{
gboolean do_frame_sync = FALSE;
/* If there is compositing there is no particular need to delay
* the swap when drawing on the offscreen, rendering to the screen
* happens later anyway, and its up to the compositor to sync that
* to the vblank. */
do_frame_sync = ! gdk_display_is_composited (display);
if (do_frame_sync != context_wgl->do_frame_sync)
{
context_wgl->do_frame_sync = do_frame_sync;
wglSwapIntervalEXT (do_frame_sync ? 1 : 0);
}
}
return TRUE;
}
static void
gdk_win32_gl_context_wgl_class_init (GdkWin32GLContextWGLClass *klass)
{
GdkGLContextClass *context_class = GDK_GL_CONTEXT_CLASS (klass);
GdkDrawContextClass *draw_context_class = GDK_DRAW_CONTEXT_CLASS (klass);
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
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-23 23:47:03 +00:00
context_class->backend_type = GDK_GL_WGL;
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-14 09:46:31 +00:00
context_class->realize = gdk_win32_gl_context_wgl_realize;
context_class->make_current = gdk_win32_gl_context_wgl_make_current;
context_class->clear_current = gdk_win32_gl_context_wgl_clear_current;
gdk: Add private GLContext::is_current() check ... and use this check in gdk_gl_context_make_current() and gdk_gl_context_get_current() to make sure the context really is still current. The context no longer being current can happen when external GL implementations make their own contexts current in the same threads GDK contexts are used in. And that can happen for example by WebKit. Theoretically, this should also allow external EGL code to run in X11 applications when GDK chooses to use GLX, but I didn't try it. Fixes #5392
2023-02-02 01:49:56 +00:00
context_class->is_current = gdk_win32_gl_context_wgl_is_current;
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
context_class->get_damage = gdk_win32_gl_context_wgl_get_damage;
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-14 09:46:31 +00:00
draw_context_class->begin_frame = gdk_win32_gl_context_wgl_begin_frame;
draw_context_class->end_frame = gdk_win32_gl_context_wgl_end_frame;
GdkWin32: Implement GdkDrawContext::empty_frame() vfunc
2024-01-30 15:20:24 +00:00
draw_context_class->empty_frame = gdk_win32_gl_context_wgl_empty_frame;
WGL: Report backbuffer's damage to GDK The backbuffer's damage region is the region of the backbuffer that doesn't contain up-to-date contents. This is determined by the backbuffer's age and previous frame's paint regions. This enables incremental rendering
2024-07-23 14:49:48 +00:00
draw_context_class->surface_resized = gdk_win32_gl_context_wgl_surface_resized;
GdkWin32: Implement GdkDrawContext::empty_frame() vfunc
2024-01-30 15:20:24 +00:00
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-14 09:46:31 +00:00
gobject_class->dispose = gdk_win32_gl_context_wgl_dispose;
}
static void
gdk_win32_gl_context_wgl_init (GdkWin32GLContextWGL *wgl_context)
{
}
/**
* gdk_win32_display_get_wgl_version:
* @display: a `GdkDisplay`
* @major: (out): return location for the WGL major version
* @minor: (out): return location for the WGL minor version
*
* Retrieves the version of the WGL implementation.
*
* Returns: %TRUE if WGL is available
*/
gboolean
gdk_win32_display_get_wgl_version (GdkDisplay *display,
win32: Get rid of display->gl_version We can just query the display's GL context. And it's not used otherwise anymore.
2023-04-26 03:54:45 +00:00
int *major,
int *minor)
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-14 09:46:31 +00:00
{
win32: Get rid of display->gl_version We can just query the display's GL context. And it's not used otherwise anymore.
2023-04-26 03:54:45 +00:00
GdkGLContext *context;
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-14 09:46:31 +00:00
g_return_val_if_fail (GDK_IS_DISPLAY (display), FALSE);
if (!GDK_IS_WIN32_DISPLAY (display))
return FALSE;
Cleanup "GDK/Win32: Try to fix initializing GLES contexts" As per Benjamin's suggestions, cleanup the previous implementation on initializing the GLES context on Windows, so that we use more items that are already in GDK proper and integrate two functions into one.
2022-01-18 02:41:28 +00:00
if (!gdk_gl_backend_can_be_used (GDK_GL_WGL, NULL))
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-14 09:46:31 +00:00
return FALSE;
win32: Get rid of display->gl_version We can just query the display's GL context. And it's not used otherwise anymore.
2023-04-26 03:54:45 +00:00
context = gdk_display_get_gl_context (display);
if (context == NULL)
return FALSE;
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-17 08:11:27 +00:00
win32: Get rid of display->gl_version We can just query the display's GL context. And it's not used otherwise anymore.
2023-04-26 03:54:45 +00:00
gdk_gl_context_get_version (context, major, minor);
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-14 09:46:31 +00:00
return TRUE;
}
Reference in New Issue Copy Permalink