AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
21057fb857
gtk2/gdk/win32/gdkglcontext-win32.c

1266 lines
37 KiB
C
Raw Normal View History

Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +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"
GdkWindow -> GdkSurface: File renames Rename all *window.[ch] source files. This is an automatic operation, done by the following commands: for i in $(git ls-files gdk | grep window); do git mv $i $(echo $i | sed s/window/surface/); git sed -f g $(basename $i) $(basename $i | sed s/window/surface/) ; done git checkout NEWS* po-properties po
2018-03-20 10:46:11 +00:00
#include "gdksurface-win32.h"
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
#include "gdkglcontext-win32.h"
#include "gdkdisplay-win32.h"
#include "gdkwin32display.h"
#include "gdkwin32glcontext.h"
#include "gdkwin32misc.h"
#include "gdkwin32screen.h"
GdkWindow -> GdkSurface: File renames Rename all *window.[ch] source files. This is an automatic operation, done by the following commands: for i in $(git ls-files gdk | grep window); do git mv $i $(echo $i | sed s/window/surface/); git sed -f g $(basename $i) $(basename $i | sed s/window/surface/) ; done git checkout NEWS* po-properties po
2018-03-20 10:46:11 +00:00
#include "gdkwin32surface.h"
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
#include "gdkglcontext.h"
GdkWindow -> GdkSurface: File renames Rename all *window.[ch] source files. This is an automatic operation, done by the following commands: for i in $(git ls-files gdk | grep window); do git mv $i $(echo $i | sed s/window/surface/); git sed -f g $(basename $i) $(basename $i | sed s/window/surface/) ; done git checkout NEWS* po-properties po
2018-03-20 10:46:11 +00:00
#include "gdksurface.h"
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
#include "gdkinternals.h"
#include "gdkintl.h"
#include <cairo.h>
#include <epoxy/wgl.h>
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
# include <epoxy/egl.h>
#endif
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
G_DEFINE_TYPE (GdkWin32GLContext, gdk_win32_gl_context, GDK_TYPE_GL_CONTEXT)
static void
_gdk_win32_gl_context_dispose (GObject *gobject)
{
GdkGLContext *context = GDK_GL_CONTEXT (gobject);
GdkWin32GLContext *context_win32 = GDK_WIN32_GL_CONTEXT (gobject);
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (gdk_gl_context_get_display (context));
gdkglcontext-win32.c: Fix window->surface changes Rename the GdkSurface variables to surface, and make sure that we are creating the context GObject correctly. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-28 04:59:47 +00:00
GdkSurface *surface = gdk_gl_context_get_surface (context);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (display_win32 != NULL)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (display_win32->have_wgl)
{
if (wglGetCurrentContext () == context_win32->hglrc)
wglMakeCurrent (NULL, NULL);
GDK_NOTE (OPENGL, g_print ("Destroying WGL context\n"));
wglDeleteContext (context_win32->hglrc);
context_win32->hglrc = NULL;
ReleaseDC (display_win32->gl_hwnd, context_win32->gl_hdc);
}
#ifdef GDK_WIN32_ENABLE_EGL
else if (display_win32->have_egl)
{
if (eglGetCurrentContext () == context_win32->egl_context)
eglMakeCurrent(display_win32->egl_disp, EGL_NO_SURFACE, EGL_NO_SURFACE,
EGL_NO_CONTEXT);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
GDK_NOTE (OPENGL, g_message ("Destroying EGL (ANGLE) context"));
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
eglDestroyContext (display_win32->egl_disp,
context_win32->egl_context);
context_win32->egl_context = EGL_NO_CONTEXT;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
ReleaseDC (display_win32->gl_hwnd, context_win32->gl_hdc);
}
#endif
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
}
G_OBJECT_CLASS (gdk_win32_gl_context_parent_class)->dispose (gobject);
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
static gboolean
_get_is_egl_force_redraw (GdkSurface *surface)
{
/* We only need to call gdk_window_invalidate_rect () if necessary */
if (surface->gl_paint_context != NULL && gdk_gl_context_get_use_es (surface->gl_paint_context))
{
GdkWin32Surface *impl = GDK_WIN32_SURFACE (surface);
return impl->egl_force_redraw_all;
}
return FALSE;
}
static void
_reset_egl_force_redraw (GdkSurface *surface)
{
if (surface->gl_paint_context != NULL && gdk_gl_context_get_use_es (surface->gl_paint_context))
{
GdkWin32Surface *impl = GDK_WIN32_SURFACE (surface);
if (impl->egl_force_redraw_all)
impl->egl_force_redraw_all = FALSE;
}
}
#endif
gdk: Large GL refactoring No visible changes as GL rendering is disabled at the moment. What was done: 1. Move window->invalidate_for_new_frame to glcontext->begin_frame This moves the code to where it is used (the GLContext) and prepares it for being called where it is used when actually beginning to draw the frame. 2. Get rid of buffer-age usage We want to let the application render directly to the backbuffer. Because of that, we cannot make any assumptions about the contents the application renders outside the clip area. In particular GskGLRenderer renders random stuff there but not actual contents. 3. Pass the actual GL context Previously, we passed the shared context to end_frame, now we pass the actual GL context that the application uses for rendering. This is so that the vfuncs could prepare the actual contexts for rendering (they don't currently). 4. Simplify the code The previous code set up the final drawing method in begin_frame. Instead, we now just ensure the clip area is something we can render and decide on the actual method in end_frame. This is both more robust (we can change the clip area in between if we want to) and less code.
2016-11-23 02:32:22 +00:00
static void
gdk: Make gdk_window_begin_draw_frame() take a draw context ... instead of a gl context. This requires some refactoring in the way we mark the shared context as drawing: We now call begin_frame/end_frame() on it and ignore the call on the main context. Unfortunately we need to do this check in all vfuncs, which sucks. But I haven't found a better way.
2016-12-01 00:38:20 +00:00
gdk_win32_gl_context_end_frame (GdkDrawContext *draw_context,
drawcontext: Only pass the region that matters We used to pass 2 regions to GdkDrawCotnext.end_frame() but code was confusing what they meant. So we now don't do that anymore and only pass the region that matters: The frame region.
2018-04-23 21:26:14 +00:00
cairo_region_t *painted)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
gdk: Make gdk_window_begin_draw_frame() take a draw context ... instead of a gl context. This requires some refactoring in the way we mark the shared context as drawing: We now call begin_frame/end_frame() on it and ignore the call on the main context. Unfortunately we need to do this check in all vfuncs, which sucks. But I haven't found a better way.
2016-12-01 00:38:20 +00:00
GdkGLContext *context = GDK_GL_CONTEXT (draw_context);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
GdkWin32GLContext *context_win32 = GDK_WIN32_GL_CONTEXT (context);
gdkglcontext-win32.c: Fix window->surface changes Rename the GdkSurface variables to surface, and make sure that we are creating the context GObject correctly. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-28 04:59:47 +00:00
GdkSurface *surface = gdk_gl_context_get_surface (context);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
GdkWin32Display *display = (GDK_WIN32_DISPLAY (gdk_gl_context_get_display (context)));
GDK/Win32: Fix build after GDKGL refactoring There were some parts that need some updates after the refactoring in GDKGL, so that the code will continue to build and run. For gdkwindow-win32.c, comment out the parts where we check for use_gl (which was removed), since we are going to move all drawing to OpenGL, but don't remove/disable the whole portion as that transition is not complete at this point. There a is new GDKGL function that checks for the damaged area of the back buffer, but since the notion of "damage" is for *NIX (GLX/EGL for Wayland/mir), meaning that there is no such extension for Windows in this regard, so we can't support this on Windows as-is, at least for now. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2016-12-06 06:37:42 +00:00
cairo_rectangle_int_t whole_window;
gdk: Make gdk_window_begin_draw_frame() take a draw context ... instead of a gl context. This requires some refactoring in the way we mark the shared context as drawing: We now call begin_frame/end_frame() on it and ignore the call on the main context. Unfortunately we need to do this check in all vfuncs, which sucks. But I haven't found a better way.
2016-12-01 00:38:20 +00:00
drawcontext: Only pass the region that matters We used to pass 2 regions to GdkDrawCotnext.end_frame() but code was confusing what they meant. So we now don't do that anymore and only pass the region that matters: The frame region.
2018-04-23 21:26:14 +00:00
GDK_DRAW_CONTEXT_CLASS (gdk_win32_gl_context_parent_class)->end_frame (draw_context, painted);
gdk: Make gdk_window_begin_draw_frame() take a draw context ... instead of a gl context. This requires some refactoring in the way we mark the shared context as drawing: We now call begin_frame/end_frame() on it and ignore the call on the main context. Unfortunately we need to do this check in all vfuncs, which sucks. But I haven't found a better way.
2016-12-01 00:38:20 +00:00
if (gdk_gl_context_get_shared_context (context))
return;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
gdk_gl_context_make_current (context);
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
whole_window = (GdkRectangle) { 0, 0, gdk_surface_get_width (surface), gdk_surface_get_height (surface) };
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (!gdk_gl_context_get_use_es (context))
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
gboolean can_wait = display->hasWglOMLSyncControl;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
if (context_win32->do_frame_sync)
{
glFinish ();
if (can_wait)
{
gint64 ust, msc, sbc;
wglGetSyncValuesOML (context_win32->gl_hdc, &ust, &msc, &sbc);
wglWaitForMscOML (context_win32->gl_hdc,
0,
2,
(msc + 1) % 2,
&ust, &msc, &sbc);
}
}
GdkGLContext: Drop gdk_gl_context_has_[framebuffer_blit|frame_terminator]() gdk_gl_context_has_framebuffer_blit() and gdk_gl_context_has_frame_terminator() were only used by by GDK/Win32, and they do not provide performance advantages in GTK master, so clean up the code a bit by dropping them.
2020-08-05 10:56:57 +00:00
SwapBuffers (context_win32->gl_hdc);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
else
gdk: Large GL refactoring No visible changes as GL rendering is disabled at the moment. What was done: 1. Move window->invalidate_for_new_frame to glcontext->begin_frame This moves the code to where it is used (the GLContext) and prepares it for being called where it is used when actually beginning to draw the frame. 2. Get rid of buffer-age usage We want to let the application render directly to the backbuffer. Because of that, we cannot make any assumptions about the contents the application renders outside the clip area. In particular GskGLRenderer renders random stuff there but not actual contents. 3. Pass the actual GL context Previously, we passed the shared context to end_frame, now we pass the actual GL context that the application uses for rendering. This is so that the vfuncs could prepare the actual contexts for rendering (they don't currently). 4. Simplify the code The previous code set up the final drawing method in begin_frame. Instead, we now just ensure the clip area is something we can render and decide on the actual method in end_frame. This is both more robust (we can change the clip area in between if we want to) and less code.
2016-11-23 02:32:22 +00:00
{
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
EGLSurface egl_surface = _gdk_win32_surface_get_egl_surface (surface, context_win32->egl_config, FALSE);
gboolean force_egl_redraw_all = _get_is_egl_force_redraw (surface);
OpenGL/ES: Fix 'R' and 'B' bits inverted on Windows We need to use GL_BGRA instead of GL_RGBA when doing glReadPixels() on EGL on Windows (ANGLE) so that the red and blue bits won't be displayed inverted. Also fix the logic where we determine whether to bit blit or redraw everything.
2018-07-31 10:18:59 +00:00
if (force_egl_redraw_all)
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
{
GdkRectangle rect = {0, 0, gdk_surface_get_width (surface), gdk_surface_get_height (surface)};
/* We need to do gdk_window_invalidate_rect() so that we don't get glitches after maximizing or
* restoring or using aerosnap
*/
gdk_surface_invalidate_rect (surface, &rect);
_reset_egl_force_redraw (surface);
}
GdkGLContext: Drop gdk_gl_context_has_[framebuffer_blit|frame_terminator]() gdk_gl_context_has_framebuffer_blit() and gdk_gl_context_has_frame_terminator() were only used by by GDK/Win32, and they do not provide performance advantages in GTK master, so clean up the code a bit by dropping them.
2020-08-05 10:56:57 +00:00
eglSwapBuffers (display->egl_disp, egl_surface);
gdk: Large GL refactoring No visible changes as GL rendering is disabled at the moment. What was done: 1. Move window->invalidate_for_new_frame to glcontext->begin_frame This moves the code to where it is used (the GLContext) and prepares it for being called where it is used when actually beginning to draw the frame. 2. Get rid of buffer-age usage We want to let the application render directly to the backbuffer. Because of that, we cannot make any assumptions about the contents the application renders outside the clip area. In particular GskGLRenderer renders random stuff there but not actual contents. 3. Pass the actual GL context Previously, we passed the shared context to end_frame, now we pass the actual GL context that the application uses for rendering. This is so that the vfuncs could prepare the actual contexts for rendering (they don't currently). 4. Simplify the code The previous code set up the final drawing method in begin_frame. Instead, we now just ensure the clip area is something we can render and decide on the actual method in end_frame. This is both more robust (we can change the clip area in between if we want to) and less code.
2016-11-23 02:32:22 +00:00
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#endif
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
}
gdk: Large GL refactoring No visible changes as GL rendering is disabled at the moment. What was done: 1. Move window->invalidate_for_new_frame to glcontext->begin_frame This moves the code to where it is used (the GLContext) and prepares it for being called where it is used when actually beginning to draw the frame. 2. Get rid of buffer-age usage We want to let the application render directly to the backbuffer. Because of that, we cannot make any assumptions about the contents the application renders outside the clip area. In particular GskGLRenderer renders random stuff there but not actual contents. 3. Pass the actual GL context Previously, we passed the shared context to end_frame, now we pass the actual GL context that the application uses for rendering. This is so that the vfuncs could prepare the actual contexts for rendering (they don't currently). 4. Simplify the code The previous code set up the final drawing method in begin_frame. Instead, we now just ensure the clip area is something we can render and decide on the actual method in end_frame. This is both more robust (we can change the clip area in between if we want to) and less code.
2016-11-23 02:32:22 +00:00
static void
gdk: Make gdk_window_begin_draw_frame() take a draw context ... instead of a gl context. This requires some refactoring in the way we mark the shared context as drawing: We now call begin_frame/end_frame() on it and ignore the call on the main context. Unfortunately we need to do this check in all vfuncs, which sucks. But I haven't found a better way.
2016-12-01 00:38:20 +00:00
gdk_win32_gl_context_begin_frame (GdkDrawContext *draw_context,
gdk: Large GL refactoring No visible changes as GL rendering is disabled at the moment. What was done: 1. Move window->invalidate_for_new_frame to glcontext->begin_frame This moves the code to where it is used (the GLContext) and prepares it for being called where it is used when actually beginning to draw the frame. 2. Get rid of buffer-age usage We want to let the application render directly to the backbuffer. Because of that, we cannot make any assumptions about the contents the application renders outside the clip area. In particular GskGLRenderer renders random stuff there but not actual contents. 3. Pass the actual GL context Previously, we passed the shared context to end_frame, now we pass the actual GL context that the application uses for rendering. This is so that the vfuncs could prepare the actual contexts for rendering (they don't currently). 4. Simplify the code The previous code set up the final drawing method in begin_frame. Instead, we now just ensure the clip area is something we can render and decide on the actual method in end_frame. This is both more robust (we can change the clip area in between if we want to) and less code.
2016-11-23 02:32:22 +00:00
cairo_region_t *update_area)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
gdk: Make gdk_window_begin_draw_frame() take a draw context ... instead of a gl context. This requires some refactoring in the way we mark the shared context as drawing: We now call begin_frame/end_frame() on it and ignore the call on the main context. Unfortunately we need to do this check in all vfuncs, which sucks. But I haven't found a better way.
2016-12-01 00:38:20 +00:00
GdkGLContext *context = GDK_GL_CONTEXT (draw_context);
gdkglcontext-win32.c: Fix window->surface changes Rename the GdkSurface variables to surface, and make sure that we are creating the context GObject correctly. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-28 04:59:47 +00:00
GdkSurface *surface;
gdkglcontext-win32.c: Fix Resizing and moving We preiously did not apply the resizes and moves as they were previously only done in the Cairo drawing context on Win32. Fix this by applying this too in the GL drawing context.
2019-04-01 06:47:36 +00:00
surface = gdk_gl_context_get_surface (context);
gdk[cairo|gl]context-win32.c: Use gdk_win32_surface_handle_queued_move_resize() Use the shared function that was added in the previous commit, to simplify things. Also make gdk_win32_surface_get_queued_window_rect() and gdk_win32_surface_apply_queued_move_resize() back into static functions, since they are now used only by the code in gdksurface-win32.c
2020-08-05 02:43:11 +00:00
gdk_win32_surface_handle_queued_move_resize (draw_context);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
GDK/Win32: Fix build after GDKGL refactoring There were some parts that need some updates after the refactoring in GDKGL, so that the code will continue to build and run. For gdkwindow-win32.c, comment out the parts where we check for use_gl (which was removed), since we are going to move all drawing to OpenGL, but don't remove/disable the whole portion as that transition is not complete at this point. There a is new GDKGL function that checks for the damaged area of the back buffer, but since the notion of "damage" is for *NIX (GLX/EGL for Wayland/mir), meaning that there is no such extension for Windows in this regard, so we can't support this on Windows as-is, at least for now. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2016-12-06 06:37:42 +00:00
GDK_DRAW_CONTEXT_CLASS (gdk_win32_gl_context_parent_class)->begin_frame (draw_context, update_area);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
}
typedef struct
{
ATOM wc_atom;
HWND hwnd;
HDC hdc;
HGLRC hglrc;
gboolean inited;
} GdkWGLDummy;
static void
_destroy_dummy_gl_context (GdkWGLDummy dummy)
{
if (dummy.hglrc != NULL)
{
wglDeleteContext (dummy.hglrc);
dummy.hglrc = NULL;
}
if (dummy.hdc != NULL)
{
DeleteDC (dummy.hdc);
dummy.hdc = NULL;
}
if (dummy.hwnd != NULL)
{
DestroyWindow (dummy.hwnd);
dummy.hwnd = NULL;
}
if (dummy.wc_atom != 0)
{
UnregisterClass (MAKEINTATOM (dummy.wc_atom), GetModuleHandle (NULL));
dummy.wc_atom = 0;
}
dummy.inited = FALSE;
}
/* Yup, we need to create a dummy window for the dummy WGL context */
static void
_get_dummy_window_hwnd (GdkWGLDummy *dummy)
{
WNDCLASSEX dummy_wc;
memset (&dummy_wc, 0, sizeof (WNDCLASSEX));
dummy_wc.cbSize = sizeof( WNDCLASSEX );
dummy_wc.style = CS_OWNDC;
dummy_wc.lpfnWndProc = (WNDPROC) DefWindowProc;
dummy_wc.cbClsExtra = 0;
dummy_wc.cbWndExtra = 0;
dummy_wc.hInstance = GetModuleHandle( NULL );
dummy_wc.hIcon = 0;
dummy_wc.hCursor = NULL;
dummy_wc.hbrBackground = 0;
dummy_wc.lpszMenuName = 0;
dummy_wc.lpszClassName = "dummy";
dummy_wc.hIconSm = 0;
dummy->wc_atom = RegisterClassEx (&dummy_wc);
dummy->hwnd =
CreateWindowEx (WS_EX_APPWINDOW,
MAKEINTATOM (dummy->wc_atom),
"",
WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN | WS_CLIPSIBLINGS,
0,
0,
0,
0,
NULL,
NULL,
GetModuleHandle (NULL),
NULL);
}
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
static int
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
_gdk_init_dummy_context (GdkWGLDummy *dummy);
#define PIXEL_ATTRIBUTES 17
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
static int
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
_get_wgl_pfd (HDC hdc,
PIXELFORMATDESCRIPTOR *pfd,
GdkWin32Display *display)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int best_pf = 0;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
pfd->nSize = sizeof (PIXELFORMATDESCRIPTOR);
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
if (display != NULL && display->hasWglARBPixelFormat)
{
GdkWGLDummy dummy;
UINT num_formats;
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int colorbits = GetDeviceCaps (hdc, BITSPIXEL);
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
guint extra_fields = 1;
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int i = 0;
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
int pixelAttribs[PIXEL_ATTRIBUTES];
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +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 ();
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
if (display->hasWglARBmultisample)
{
/* 2 pairs of values needed for multisampling/AA support */
extra_fields += 2 * 2;
}
/* Update PIXEL_ATTRIBUTES above if any groups are added here! */
/* one group contains a value pair for both pixelAttribs and pixelAttribsNoAlpha */
pixelAttribs[i] = WGL_DRAW_TO_WINDOW_ARB;
pixelAttribs[i++] = GL_TRUE;
pixelAttribs[i++] = WGL_SUPPORT_OPENGL_ARB;
pixelAttribs[i++] = GL_TRUE;
pixelAttribs[i++] = WGL_DOUBLE_BUFFER_ARB;
pixelAttribs[i++] = GL_TRUE;
pixelAttribs[i++] = WGL_ACCELERATION_ARB;
pixelAttribs[i++] = WGL_FULL_ACCELERATION_ARB;
pixelAttribs[i++] = WGL_PIXEL_TYPE_ARB;
pixelAttribs[i++] = WGL_TYPE_RGBA_ARB;
pixelAttribs[i++] = WGL_COLOR_BITS_ARB;
pixelAttribs[i++] = colorbits;
/* end of "Update PIXEL_ATTRIBUTES above if any groups are added here!" */
if (display->hasWglARBmultisample)
{
pixelAttribs[i++] = WGL_SAMPLE_BUFFERS_ARB;
pixelAttribs[i++] = 1;
pixelAttribs[i++] = WGL_SAMPLES_ARB;
pixelAttribs[i++] = 8;
}
pixelAttribs[i++] = 0; /* end of pixelAttribs */
memset (&dummy, 0, sizeof (GdkWGLDummy));
/* acquire and cache dummy Window (HWND & HDC) and
* dummy GL Context, we need it for wglChoosePixelFormatARB()
*/
best_pf = _gdk_init_dummy_context (&dummy);
if (best_pf == 0 || !wglMakeCurrent (dummy.hdc, dummy.hglrc))
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +00:00
{
wglMakeCurrent (hdc_current, hglrc_current);
return 0;
}
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
wglChoosePixelFormatARB (hdc,
pixelAttribs,
NULL,
1,
&best_pf,
&num_formats);
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +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);
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
_destroy_dummy_gl_context (dummy);
}
else
{
pfd->nVersion = 1;
pfd->dwFlags = PFD_SUPPORT_OPENGL | PFD_DRAW_TO_WINDOW | PFD_DOUBLEBUFFER;
pfd->iPixelType = PFD_TYPE_RGBA;
pfd->cColorBits = GetDeviceCaps (hdc, BITSPIXEL);
pfd->cAlphaBits = 8;
pfd->dwLayerMask = PFD_MAIN_PLANE;
best_pf = ChoosePixelFormat (hdc, pfd);
}
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +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
*/
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
static int
API: gdk: Remove gdk_window_get_visual() With it, remove window->visual.
2016-10-27 21:27:49 +00:00
_gdk_init_dummy_context (GdkWGLDummy *dummy)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
PIXELFORMATDESCRIPTOR pfd;
gboolean set_pixel_format_result = FALSE;
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int best_idx = 0;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
_get_dummy_window_hwnd (dummy);
dummy->hdc = GetDC (dummy->hwnd);
memset (&pfd, 0, sizeof (PIXELFORMATDESCRIPTOR));
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
best_idx = _get_wgl_pfd (dummy->hdc, &pfd, NULL);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
if (best_idx != 0)
set_pixel_format_result = SetPixelFormat (dummy->hdc,
best_idx,
&pfd);
if (best_idx == 0 || !set_pixel_format_result)
return 0;
dummy->hglrc = wglCreateContext (dummy->hdc);
if (dummy->hglrc == NULL)
return 0;
dummy->inited = TRUE;
return best_idx;
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
#ifndef EGL_PLATFORM_ANGLE_ANGLE
#define EGL_PLATFORM_ANGLE_ANGLE 0x3202
#endif
#ifndef EGL_PLATFORM_ANGLE_TYPE_ANGLE
#define EGL_PLATFORM_ANGLE_TYPE_ANGLE 0x3203
#endif
#ifndef EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE
#define EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE 0x3208
#endif
static EGLDisplay
_gdk_win32_get_egl_display (GdkWin32Display *display)
{
EGLDisplay disp;
if (epoxy_has_egl_extension (NULL, "EGL_EXT_platform_base"))
{
PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplay = (void *) eglGetProcAddress ("eglGetPlatformDisplayEXT");
if (getPlatformDisplay)
{
EGLint disp_attr[] = {EGL_PLATFORM_ANGLE_TYPE_ANGLE, EGL_PLATFORM_ANGLE_TYPE_D3D11_ANGLE, EGL_NONE};
disp = getPlatformDisplay (EGL_PLATFORM_ANGLE_ANGLE, display->hdc_egl_temp, disp_attr);
if (disp != EGL_NO_DISPLAY)
return disp;
}
}
return eglGetDisplay (display->hdc_egl_temp);
}
#endif
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +00:00
static gboolean
API: gdk: Remove gdk_window_get_visual() With it, remove window->visual.
2016-10-27 21:27:49 +00:00
_gdk_win32_display_init_gl (GdkDisplay *display)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (display);
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int best_idx = 0;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
gboolean disable_wgl = FALSE;
#ifdef GDK_WIN32_ENABLE_EGL
EGLDisplay egl_disp;
GDK/Win32: Force GLES if running on ARM64 If GLES support is enabled on Windows, force GLES mode if we are running on a ARM64 version of Windows (i.e. Windows 10 for ARM). This is required as ARM64 versions of Windows only provide a software implementation of OpenGL 1.1/1.2, which is not enough for our purposes. Thus, we could make instead use the GLES support provided via Google's libANGLE (which emulates OpenGL/ES 3 with Direct3D 9/11), so that we can run GtkGLArea programs under OpenGL/ES in ARM64 versions of Windows. Note that eventually we could update the libepoxy build files for Windows to not check nor enable WGL when building for ARM64 Windows, as the WGL items do not work, although they do build.
2019-05-07 07:09:03 +00:00
disable_wgl = GDK_DISPLAY_DEBUG_CHECK (display, GL_GLES) ||
display_win32->running_on_arm64;
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#endif
if (display_win32->have_wgl
#ifdef GDK_WIN32_ENABLE_EGL
|| display_win32->have_egl
#endif
)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
return TRUE;
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (!disable_wgl)
{
GdkWGLDummy dummy;
memset (&dummy, 0, sizeof (GdkWGLDummy));
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +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
*/
best_idx = _gdk_init_dummy_context (&dummy);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (best_idx == 0 || !wglMakeCurrent (dummy.hdc, dummy.hglrc))
return FALSE;
display_win32->have_wgl = TRUE;
display_win32->gl_version = epoxy_gl_version ();
display_win32->hasWglARBCreateContext =
epoxy_has_wgl_extension (dummy.hdc, "WGL_ARB_create_context");
display_win32->hasWglEXTSwapControl =
epoxy_has_wgl_extension (dummy.hdc, "WGL_EXT_swap_control");
display_win32->hasWglOMLSyncControl =
epoxy_has_wgl_extension (dummy.hdc, "WGL_OML_sync_control");
display_win32->hasWglARBPixelFormat =
epoxy_has_wgl_extension (dummy.hdc, "WGL_ARB_pixel_format");
display_win32->hasWglARBmultisample =
epoxy_has_wgl_extension (dummy.hdc, "WGL_ARB_multisample");
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"
"\t* WGL_OML_sync_control: %s\n"
"\t* WGL_ARB_multisample: %s\n",
display_win32->gl_version / 10,
display_win32->gl_version % 10,
glGetString (GL_VENDOR),
display_win32->hasWglARBPixelFormat ? "yes" : "no",
display_win32->hasWglARBCreateContext ? "yes" : "no",
display_win32->hasWglEXTSwapControl ? "yes" : "no",
display_win32->hasWglOMLSyncControl ? "yes" : "no",
display_win32->hasWglARBmultisample ? "yes" : "no"));
wglMakeCurrent (NULL, NULL);
_destroy_dummy_gl_context (dummy);
}
#ifdef GDK_WIN32_ENABLE_EGL
else
{
egl_disp = _gdk_win32_get_egl_display (display_win32);
if (egl_disp == EGL_NO_DISPLAY || !eglInitialize (egl_disp, NULL, NULL))
{
if (egl_disp != EGL_NO_DISPLAY)
{
eglTerminate (egl_disp);
egl_disp = EGL_NO_DISPLAY;
}
return FALSE;
}
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
display_win32->egl_disp = egl_disp;
display_win32->have_egl = TRUE;
display_win32->egl_version = epoxy_egl_version (egl_disp);
eglBindAPI(EGL_OPENGL_ES_API);
display_win32->hasEglSurfacelessContext =
epoxy_has_egl_extension (egl_disp, "EGL_KHR_surfaceless_context");
GDK_NOTE (OPENGL,
g_print ("EGL API version %d.%d found\n"
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
" - Vendor: %s\n"
" - Checked extensions:\n"
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
"\t* EGL_KHR_surfaceless_context: %s\n",
display_win32->egl_version / 10,
display_win32->egl_version % 10,
eglQueryString (display_win32->egl_disp, EGL_VENDOR),
display_win32->hasEglSurfacelessContext ? "yes" : "no"));
}
#endif
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
return TRUE;
}
Win32: Add EGLDisplay getter Like what was done for Wayland and X11, add an API to retrieve the EGLDisplay if one is being used in place of WGL.
2021-05-12 11:29:05 +00:00
/**
* gdk_win32_display_get_egl_display:
* @display: (type GdkWin32Display): a Win32 display
*
* Retrieves the EGL display connection object for the given GDK display.
*
* Returns: (nullable): the EGL display
*/
gpointer
gdk_win32_display_get_egl_display (GdkDisplay *display)
{
GdkWin32Display *display_win32;
g_return_val_if_fail (GDK_IS_WIN32_DISPLAY (display), NULL);
#ifdef GDK_WIN32_ENABLE_EGL
if (!_gdk_win32_display_init_gl (display))
return NULL;
display_win32 = GDK_WIN32_DISPLAY (display);
if (display_win32->have_wgl)
return NULL;
return display_win32->egl_disp;
#else
/* no EGL support */
return NULL;
#endif
}
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
/* Setup the legacy context after creating it */
static gboolean
_ensure_legacy_gl_context (HDC hdc,
HGLRC hglrc_legacy,
GdkGLContext *share)
{
GdkWin32GLContext *context_win32;
if (!wglMakeCurrent (hdc, hglrc_legacy))
return FALSE;
if (share != NULL)
{
context_win32 = GDK_WIN32_GL_CONTEXT (share);
return wglShareLists (hglrc_legacy, context_win32->hglrc);
}
return TRUE;
}
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
static HGLRC
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
_create_gl_context_with_attribs (HDC hdc,
HGLRC hglrc_base,
GdkGLContext *share,
int flags,
int major,
int minor,
gboolean *is_legacy)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
Remove GdkGLProfile The existence of OpenGL implementations that do not provide the full core profile compatibility because of reasons beyond the technical, like llvmpipe not implementing floating point buffers, makes the existence of GdkGLProfile and documenting the fact that we use core profiles a bit harder. Since we do not have any existing profile except the default, we can remove the GdkGLProfile and its related API from GDK and GTK+, and sweep the whole thing under the carpet, while we wait for an extension that lets us ask for the most compatible profile possible. https://bugzilla.gnome.org/show_bug.cgi?id=744407
2015-02-12 17:30:42 +00:00
HGLRC hglrc;
GdkWin32GLContext *context_win32;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
/* 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, *is_legacy ? 3 : major,
WGL_CONTEXT_MINOR_VERSION_ARB, *is_legacy ? 0 : minor,
WGL_CONTEXT_FLAGS_ARB, flags,
Remove GdkGLProfile The existence of OpenGL implementations that do not provide the full core profile compatibility because of reasons beyond the technical, like llvmpipe not implementing floating point buffers, makes the existence of GdkGLProfile and documenting the fact that we use core profiles a bit harder. Since we do not have any existing profile except the default, we can remove the GdkGLProfile and its related API from GDK and GTK+, and sweep the whole thing under the carpet, while we wait for an extension that lets us ask for the most compatible profile possible. https://bugzilla.gnome.org/show_bug.cgi?id=744407
2015-02-12 17:30:42 +00:00
0
};
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Remove GdkGLProfile The existence of OpenGL implementations that do not provide the full core profile compatibility because of reasons beyond the technical, like llvmpipe not implementing floating point buffers, makes the existence of GdkGLProfile and documenting the fact that we use core profiles a bit harder. Since we do not have any existing profile except the default, we can remove the GdkGLProfile and its related API from GDK and GTK+, and sweep the whole thing under the carpet, while we wait for an extension that lets us ask for the most compatible profile possible. https://bugzilla.gnome.org/show_bug.cgi?id=744407
2015-02-12 17:30:42 +00:00
if (share != NULL)
context_win32 = GDK_WIN32_GL_CONTEXT (share);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Remove GdkGLProfile The existence of OpenGL implementations that do not provide the full core profile compatibility because of reasons beyond the technical, like llvmpipe not implementing floating point buffers, makes the existence of GdkGLProfile and documenting the fact that we use core profiles a bit harder. Since we do not have any existing profile except the default, we can remove the GdkGLProfile and its related API from GDK and GTK+, and sweep the whole thing under the carpet, while we wait for an extension that lets us ask for the most compatible profile possible. https://bugzilla.gnome.org/show_bug.cgi?id=744407
2015-02-12 17:30:42 +00:00
hglrc = wglCreateContextAttribsARB (hdc,
share != NULL ? context_win32->hglrc : NULL,
attribs);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Remove GdkGLProfile The existence of OpenGL implementations that do not provide the full core profile compatibility because of reasons beyond the technical, like llvmpipe not implementing floating point buffers, makes the existence of GdkGLProfile and documenting the fact that we use core profiles a bit harder. Since we do not have any existing profile except the default, we can remove the GdkGLProfile and its related API from GDK and GTK+, and sweep the whole thing under the carpet, while we wait for an extension that lets us ask for the most compatible profile possible. https://bugzilla.gnome.org/show_bug.cgi?id=744407
2015-02-12 17:30:42 +00:00
return hglrc;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
}
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
static HGLRC
_create_gl_context (HDC hdc,
GdkGLContext *share,
int flags,
int major,
int minor,
gboolean *is_legacy,
gboolean hasWglARBCreateContext)
{
/* We need a legacy context for *all* cases */
HGLRC hglrc_base = wglCreateContext (hdc);
gboolean success = TRUE;
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +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 ();
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
/* if we have no wglCreateContextAttribsARB(), return the legacy context when all is set */
if (*is_legacy && !hasWglARBCreateContext)
{
if (_ensure_legacy_gl_context (hdc, hglrc_base, share))
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +00:00
{
wglMakeCurrent (hdc_current, hglrc_current);
return hglrc_base;
}
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
success = FALSE;
goto gl_fail;
}
else
{
HGLRC hglrc;
if (!wglMakeCurrent (hdc, hglrc_base))
{
success = FALSE;
goto gl_fail;
}
hglrc = _create_gl_context_with_attribs (hdc,
hglrc_base,
share,
flags,
major,
minor,
is_legacy);
/* return the legacy context we have if it could be setup properly, in case the 3.0+ context creation failed */
if (hglrc == NULL)
{
if (!(*is_legacy))
{
/* If we aren't using a legacy context in the beginning, try again with a compatibility profile 3.0 context */
hglrc = _create_gl_context_with_attribs (hdc,
hglrc_base,
share,
flags,
0, 0,
is_legacy);
*is_legacy = TRUE;
}
if (hglrc == NULL)
{
if (!_ensure_legacy_gl_context (hdc, hglrc_base, share))
success = FALSE;
}
if (success)
GDK_NOTE (OPENGL, g_print ("Using legacy context as fallback\n"));
}
gl_fail:
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +00:00
if (!success)
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
{
wglMakeCurrent (NULL, NULL);
wglDeleteContext (hglrc_base);
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +00:00
return NULL;
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
}
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +00:00
wglMakeCurrent (hdc_current, hglrc_current);
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
if (hglrc != NULL)
gdk/win32: Fix Win32 GL Context switching Since on Windows we need to use a good amount of temporary GL contexts, we need to switch back to the original GL contexts we were using when we are done with the temporary GL contexts, otherwise multi-GL windows will cause confusions causing display artifacts and crashes. Also, use the GdkWin32GLContext::gl_hdc consistently throughout the code and remove the GdkWin32Display::gl_hdc as Lukas K pointed out that GdkWin32Display::gl_hdc becomes out-of-date and so the HDC that the GL context is bound to becomes incorrect in sceanarios using multiple windows with GtkGLArea/GdkGLArea items (which would cause the artifacts in programs that use multiple windows with GtkGLArea/GdkGLArea items, and it turns out that GdkWin32Display::gl_hdc is actually not necessary to help keep track of the HDCs we use for our GL contexts. This will also fix on Windows with GDK_GL=always, or when GSK's gl renderer is used. Partly based on patch from Lukas K <lu@0x83.eu> https://bugzilla.gnome.org/show_bug.cgi?id=789213
2017-10-30 07:00:28 +00:00
{
wglDeleteContext (hglrc_base);
return hglrc;
}
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
return hglrc_base;
}
}
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
static gboolean
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
_set_pixformat_for_hdc (HDC hdc,
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int *best_idx,
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
GdkWin32Display *display)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
gdkglcontext-win32.c: Fix running with Mesa drivers Some GL drivers such as Mesa-D3D12 do not allow one to call SetPixelFormat() on a given HDC if one pixel format has been already set for it, so first check the HDC with GetPixelFormat() to see whether a pixel format has already been set with the HDC, and only attempt to acquire the pixel format if one has not been set. This will fix running with GL/NGL on Windows using the Mesa drivers.
2021-04-29 04:04:42 +00:00
gboolean already_checked = TRUE;
*best_idx = GetPixelFormat (hdc);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
/* one is only allowed to call SetPixelFormat(), and so ChoosePixelFormat()
* one single time per window HDC
*/
gdkglcontext-win32.c: Fix running with Mesa drivers Some GL drivers such as Mesa-D3D12 do not allow one to call SetPixelFormat() on a given HDC if one pixel format has been already set for it, so first check the HDC with GetPixelFormat() to see whether a pixel format has already been set with the HDC, and only attempt to acquire the pixel format if one has not been set. This will fix running with GL/NGL on Windows using the Mesa drivers.
2021-04-29 04:04:42 +00:00
if (*best_idx == 0)
{
PIXELFORMATDESCRIPTOR pfd;
gboolean set_pixel_format_result = FALSE;
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
gdkglcontext-win32.c: Fix running with Mesa drivers Some GL drivers such as Mesa-D3D12 do not allow one to call SetPixelFormat() on a given HDC if one pixel format has been already set for it, so first check the HDC with GetPixelFormat() to see whether a pixel format has already been set with the HDC, and only attempt to acquire the pixel format if one has not been set. This will fix running with GL/NGL on Windows using the Mesa drivers.
2021-04-29 04:04:42 +00:00
GDK_NOTE (OPENGL, g_print ("requesting pixel format...\n"));
already_checked = FALSE;
*best_idx = _get_wgl_pfd (hdc, &pfd, display);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
gdkglcontext-win32.c: Fix running with Mesa drivers Some GL drivers such as Mesa-D3D12 do not allow one to call SetPixelFormat() on a given HDC if one pixel format has been already set for it, so first check the HDC with GetPixelFormat() to see whether a pixel format has already been set with the HDC, and only attempt to acquire the pixel format if one has not been set. This will fix running with GL/NGL on Windows using the Mesa drivers.
2021-04-29 04:04:42 +00:00
if (*best_idx != 0)
set_pixel_format_result = SetPixelFormat (hdc, *best_idx, &pfd);
/* 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", already_checked ? "already " : "", *best_idx));
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
return TRUE;
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
#define MAX_EGL_ATTRS 30
static gboolean
find_eglconfig_for_window (GdkWin32Display *display,
EGLConfig *egl_config_out,
EGLint *min_swap_interval_out,
GError **error)
{
EGLint attrs[MAX_EGL_ATTRS];
EGLint count;
EGLConfig *configs, chosen_config;
int i = 0;
EGLDisplay egl_disp = display->egl_disp;
attrs[i++] = EGL_CONFORMANT;
attrs[i++] = EGL_OPENGL_ES2_BIT;
attrs[i++] = EGL_SURFACE_TYPE;
attrs[i++] = EGL_WINDOW_BIT;
attrs[i++] = EGL_COLOR_BUFFER_TYPE;
attrs[i++] = EGL_RGB_BUFFER;
attrs[i++] = EGL_RED_SIZE;
attrs[i++] = 1;
attrs[i++] = EGL_GREEN_SIZE;
attrs[i++] = 1;
attrs[i++] = EGL_BLUE_SIZE;
attrs[i++] = 1;
attrs[i++] = EGL_ALPHA_SIZE;
attrs[i++] = 1;
attrs[i++] = EGL_NONE;
g_assert (i < MAX_EGL_ATTRS);
if (!eglChooseConfig (display->egl_disp, attrs, NULL, 0, &count) || count < 1)
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_UNSUPPORTED_FORMAT,
_("No available configurations for the given pixel format"));
return FALSE;
}
configs = g_new (EGLConfig, count);
if (!eglChooseConfig (display->egl_disp, attrs, configs, count, &count) || count < 1)
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_UNSUPPORTED_FORMAT,
_("No available configurations for the given pixel format"));
return FALSE;
}
/* Pick first valid configuration i guess? */
chosen_config = configs[0];
if (!eglGetConfigAttrib (display->egl_disp, chosen_config,
EGL_MIN_SWAP_INTERVAL, min_swap_interval_out))
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
"Could not retrieve the minimum swap interval");
g_free (configs);
return FALSE;
}
if (egl_config_out != NULL)
*egl_config_out = chosen_config;
g_free (configs);
return TRUE;
}
#define N_EGL_ATTRS 16
static EGLContext
_create_egl_context (EGLDisplay display,
EGLConfig config,
GdkGLContext *share,
int flags,
int major,
int minor,
gboolean *is_legacy)
{
EGLContext ctx;
EGLint context_attribs[N_EGL_ATTRS];
int i = 0;
/* ANGLE does not support the GL_OES_vertex_array_object extension, so we need to use ES3 directly */
context_attribs[i++] = EGL_CONTEXT_CLIENT_VERSION;
context_attribs[i++] = 3;
/* Specify the flags */
context_attribs[i++] = EGL_CONTEXT_FLAGS_KHR;
context_attribs[i++] = flags;
context_attribs[i++] = EGL_NONE;
g_assert (i < N_EGL_ATTRS);
ctx = eglCreateContext (display,
config,
share != NULL ? GDK_WIN32_GL_CONTEXT (share)->egl_context
: EGL_NO_CONTEXT,
context_attribs);
if (ctx != EGL_NO_CONTEXT)
GDK_NOTE (OPENGL, g_message ("Created EGL context[%p]", ctx));
return ctx;
}
#endif /* GDK_WIN32_ENABLE_EGL */
gdk: Large GL refactoring No visible changes as GL rendering is disabled at the moment. What was done: 1. Move window->invalidate_for_new_frame to glcontext->begin_frame This moves the code to where it is used (the GLContext) and prepares it for being called where it is used when actually beginning to draw the frame. 2. Get rid of buffer-age usage We want to let the application render directly to the backbuffer. Because of that, we cannot make any assumptions about the contents the application renders outside the clip area. In particular GskGLRenderer renders random stuff there but not actual contents. 3. Pass the actual GL context Previously, we passed the shared context to end_frame, now we pass the actual GL context that the application uses for rendering. This is so that the vfuncs could prepare the actual contexts for rendering (they don't currently). 4. Simplify the code The previous code set up the final drawing method in begin_frame. Instead, we now just ensure the clip area is something we can render and decide on the actual method in end_frame. This is both more robust (we can change the clip area in between if we want to) and less code.
2016-11-23 02:32:22 +00:00
static gboolean
gdk_win32_gl_context_realize (GdkGLContext *context,
GError **error)
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
{
GdkGLContext *share = gdk_gl_context_get_shared_context (context);
gdkglcontext-win32.c: Create a global shared GL context Like the other backends, we ought to create our WGL/EGL GL contexts like the following: "Create a global GL context that connects all GL contexts on a display and lets us share textures between them."
2020-07-31 10:37:05 +00:00
GdkGLContext *shared_data_context;
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
GdkWin32GLContext *context_win32 = GDK_WIN32_GL_CONTEXT (context);
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
gboolean debug_bit, compat_bit, legacy_bit;
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
gboolean use_es = FALSE;
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
gdkglcontext-win32.c: Fix Build on C89 Compilers Make sure variables are declared at the top of the block.
2015-02-13 10:36:34 +00:00
/* request flags and specific versions for core (3.2+) WGL context */
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int flags = 0;
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
int major = 0;
int minor = 0;
gdkglcontext-win32.c: Fix Build on C89 Compilers Make sure variables are declared at the top of the block.
2015-02-13 10:36:34 +00:00
gdkglcontext-win32.c: Fix window->surface changes Rename the GdkSurface variables to surface, and make sure that we are creating the context GObject correctly. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-28 04:59:47 +00:00
GdkSurface *surface = gdk_gl_context_get_surface (context);
win32: Build fixes
2019-05-19 03:09:05 +00:00
GdkWin32Surface *impl = GDK_WIN32_SURFACE (surface);
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
GdkDisplay *display = gdk_surface_get_display (surface);
GdkWin32Display *win32_display = GDK_WIN32_DISPLAY (display);
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
gdk_gl_context_get_required_version (context, &major, &minor);
Remove GdkGLProfile The existence of OpenGL implementations that do not provide the full core profile compatibility because of reasons beyond the technical, like llvmpipe not implementing floating point buffers, makes the existence of GdkGLProfile and documenting the fact that we use core profiles a bit harder. Since we do not have any existing profile except the default, we can remove the GdkGLProfile and its related API from GDK and GTK+, and sweep the whole thing under the carpet, while we wait for an extension that lets us ask for the most compatible profile possible. https://bugzilla.gnome.org/show_bug.cgi?id=744407
2015-02-12 17:30:42 +00:00
debug_bit = gdk_gl_context_get_debug_enabled (context);
compat_bit = gdk_gl_context_get_forward_compatible (context);
gdkglcontext-win32.c: Create a global shared GL context Like the other backends, we ought to create our WGL/EGL GL contexts like the following: "Create a global GL context that connects all GL contexts on a display and lets us share textures between them."
2020-07-31 10:37:05 +00:00
shared_data_context = gdk_surface_get_shared_data_gl_context (surface);
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +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
*/
if (share != NULL && gdk_gl_context_is_legacy (share))
legacy_bit = TRUE;
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
/* if GDK_GL_LEGACY is set, we default to a legacy context */
legacy_bit = g_getenv ("GDK_GL_LEGACY") != NULL;
use_es = GDK_DISPLAY_DEBUG_CHECK (display, GL_GLES) ||
(share != NULL && gdk_gl_context_get_use_es (share));
if (win32_display->have_wgl || !use_es)
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
{
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
/* These are the real WGL context items that we will want to use later */
HGLRC hglrc;
int pixel_format;
if (!_set_pixformat_for_hdc (context_win32->gl_hdc,
&pixel_format,
win32_display))
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_UNSUPPORTED_FORMAT,
_("No available configurations for the given pixel format"));
return FALSE;
}
/* if there isn't wglCreateContextAttribsARB() on WGL, use a legacy context */
if (!legacy_bit)
legacy_bit = !win32_display->hasWglARBCreateContext;
if (debug_bit)
flags |= WGL_CONTEXT_DEBUG_BIT_ARB;
if (compat_bit)
flags |= WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB;
GDK_NOTE (OPENGL,
g_print ("Creating %s WGL context (version:%d.%d, debug:%s, forward:%s, legacy: %s)\n",
compat_bit ? "core" : "compat",
major,
minor,
debug_bit ? "yes" : "no",
compat_bit ? "yes" : "no",
legacy_bit ? "yes" : "no"));
hglrc = _create_gl_context (context_win32->gl_hdc,
gdkglcontext-win32.c: Create a global shared GL context Like the other backends, we ought to create our WGL/EGL GL contexts like the following: "Create a global GL context that connects all GL contexts on a display and lets us share textures between them."
2020-07-31 10:37:05 +00:00
share ? share : shared_data_context,
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
flags,
major,
minor,
&legacy_bit,
win32_display->hasWglARBCreateContext);
if (hglrc == NULL)
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("Unable to create a GL context"));
return FALSE;
}
GDK_NOTE (OPENGL,
g_print ("Created WGL context[%p], pixel_format=%d\n",
hglrc,
pixel_format));
context_win32->hglrc = hglrc;
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
else
{
EGLContext egl_context;
EGLContext ctx;
if (debug_bit)
flags |= EGL_CONTEXT_OPENGL_DEBUG_BIT_KHR;
if (compat_bit)
flags |= EGL_CONTEXT_OPENGL_FORWARD_COMPATIBLE_BIT_KHR;
GDK_NOTE (OPENGL, g_message ("Creating EGL context version %d.%d (debug:%s, forward:%s, legacy:%s)",
major, minor,
debug_bit ? "yes" : "no",
compat_bit ? "yes" : "no",
legacy_bit ? "yes" : "no"));
ctx = _create_egl_context (win32_display->egl_disp,
context_win32->egl_config,
gdkglcontext-win32.c: Create a global shared GL context Like the other backends, we ought to create our WGL/EGL GL contexts like the following: "Create a global GL context that connects all GL contexts on a display and lets us share textures between them."
2020-07-31 10:37:05 +00:00
share ? share : shared_data_context,
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
flags,
major,
minor,
&legacy_bit);
if (ctx == EGL_NO_CONTEXT)
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("Unable to create a GL context"));
return FALSE;
}
GDK_NOTE (OPENGL,
g_print ("Created EGL context[%p]\n",
ctx));
context_win32->egl_context = ctx;
use_es = TRUE;
}
#endif
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
/* set whether we are using GLES */
gdk_gl_context_set_use_es (context, use_es);
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
GDK-Win32/4.0: Improve GL on Windows Update the GDKGL implementation: -Allow legacy contexts to be created. -Use finer-grained attributes to ask for a pixel format when possible, which also adds support for anti-aliasing In fact the changes here are required for GTKGL to work properly on Windows for 4.x. Note that creation of gles contexts is not done here, as the system does not support such contexts directly on Windows, but only through means such as ANGLE, which is a totally different issue here. https://bugzilla.gnome.org/show_bug.cgi?id=773528
2016-10-14 11:04:49 +00:00
/* Ensure that any other context is created with a legacy bit set */
gdk_gl_context_set_is_legacy (context, legacy_bit);
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
return TRUE;
}
gdk: Large GL refactoring No visible changes as GL rendering is disabled at the moment. What was done: 1. Move window->invalidate_for_new_frame to glcontext->begin_frame This moves the code to where it is used (the GLContext) and prepares it for being called where it is used when actually beginning to draw the frame. 2. Get rid of buffer-age usage We want to let the application render directly to the backbuffer. Because of that, we cannot make any assumptions about the contents the application renders outside the clip area. In particular GskGLRenderer renders random stuff there but not actual contents. 3. Pass the actual GL context Previously, we passed the shared context to end_frame, now we pass the actual GL context that the application uses for rendering. This is so that the vfuncs could prepare the actual contexts for rendering (they don't currently). 4. Simplify the code The previous code set up the final drawing method in begin_frame. Instead, we now just ensure the clip area is something we can render and decide on the actual method in end_frame. This is both more robust (we can change the clip area in between if we want to) and less code.
2016-11-23 02:32:22 +00:00
static void
gdk_win32_gl_context_class_init (GdkWin32GLContextClass *klass)
{
GDK/Win32: Fix build after GDKGL refactoring There were some parts that need some updates after the refactoring in GDKGL, so that the code will continue to build and run. For gdkwindow-win32.c, comment out the parts where we check for use_gl (which was removed), since we are going to move all drawing to OpenGL, but don't remove/disable the whole portion as that transition is not complete at this point. There a is new GDKGL function that checks for the damaged area of the back buffer, but since the notion of "damage" is for *NIX (GLX/EGL for Wayland/mir), meaning that there is no such extension for Windows in this regard, so we can't support this on Windows as-is, at least for now. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2016-12-06 06:37:42 +00:00
GdkGLContextClass *gl_context_class = GDK_GL_CONTEXT_CLASS(klass);
GdkDrawContextClass *draw_context_class = GDK_DRAW_CONTEXT_CLASS(klass);
gdk: Large GL refactoring No visible changes as GL rendering is disabled at the moment. What was done: 1. Move window->invalidate_for_new_frame to glcontext->begin_frame This moves the code to where it is used (the GLContext) and prepares it for being called where it is used when actually beginning to draw the frame. 2. Get rid of buffer-age usage We want to let the application render directly to the backbuffer. Because of that, we cannot make any assumptions about the contents the application renders outside the clip area. In particular GskGLRenderer renders random stuff there but not actual contents. 3. Pass the actual GL context Previously, we passed the shared context to end_frame, now we pass the actual GL context that the application uses for rendering. This is so that the vfuncs could prepare the actual contexts for rendering (they don't currently). 4. Simplify the code The previous code set up the final drawing method in begin_frame. Instead, we now just ensure the clip area is something we can render and decide on the actual method in end_frame. This is both more robust (we can change the clip area in between if we want to) and less code.
2016-11-23 02:32:22 +00:00
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
GDK/Win32: Fix build after GDKGL refactoring There were some parts that need some updates after the refactoring in GDKGL, so that the code will continue to build and run. For gdkwindow-win32.c, comment out the parts where we check for use_gl (which was removed), since we are going to move all drawing to OpenGL, but don't remove/disable the whole portion as that transition is not complete at this point. There a is new GDKGL function that checks for the damaged area of the back buffer, but since the notion of "damage" is for *NIX (GLX/EGL for Wayland/mir), meaning that there is no such extension for Windows in this regard, so we can't support this on Windows as-is, at least for now. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2016-12-06 06:37:42 +00:00
gl_context_class->realize = gdk_win32_gl_context_realize;
draw_context_class->begin_frame = gdk_win32_gl_context_begin_frame;
draw_context_class->end_frame = gdk_win32_gl_context_end_frame;
gdk: Large GL refactoring No visible changes as GL rendering is disabled at the moment. What was done: 1. Move window->invalidate_for_new_frame to glcontext->begin_frame This moves the code to where it is used (the GLContext) and prepares it for being called where it is used when actually beginning to draw the frame. 2. Get rid of buffer-age usage We want to let the application render directly to the backbuffer. Because of that, we cannot make any assumptions about the contents the application renders outside the clip area. In particular GskGLRenderer renders random stuff there but not actual contents. 3. Pass the actual GL context Previously, we passed the shared context to end_frame, now we pass the actual GL context that the application uses for rendering. This is so that the vfuncs could prepare the actual contexts for rendering (they don't currently). 4. Simplify the code The previous code set up the final drawing method in begin_frame. Instead, we now just ensure the clip area is something we can render and decide on the actual method in end_frame. This is both more robust (we can change the clip area in between if we want to) and less code.
2016-11-23 02:32:22 +00:00
gobject_class->dispose = _gdk_win32_gl_context_dispose;
}
static void
gdk_win32_gl_context_init (GdkWin32GLContext *self)
{
}
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
GdkGLContext *
gdkglcontext-win32.c: Fix window->surface changes Rename the GdkSurface variables to surface, and make sure that we are creating the context GObject correctly. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-28 04:59:47 +00:00
_gdk_win32_surface_create_gl_context (GdkSurface *surface,
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
gboolean attached,
GdkGLContext *share,
GError **error)
{
gdkglcontext-win32.c: Fix window->surface changes Rename the GdkSurface variables to surface, and make sure that we are creating the context GObject correctly. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-28 04:59:47 +00:00
GdkDisplay *display = gdk_surface_get_display (surface);
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (display);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
GdkWin32GLContext *context = NULL;
GDK-Win32: Split GL context creation in two phases Like what is being done in the X11 and Wayland backends, create the GdkWin32GLContext in 2 steps, where we only create the actual WGL context in _gdk_win32_gl_context_realize(). https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-30 05:53:31 +00:00
/* Acquire and store up the Windows-specific HWND and HDC */
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
/* HWND hwnd;*/
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
HDC hdc;
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
EGLContext egl_context;
EGLConfig config;
#endif
display_win32->gl_hwnd = GDK_SURFACE_HWND (surface);
hdc = GetDC (display_win32->gl_hwnd);
#ifdef GDK_WIN32_ENABLE_EGL
/* display_win32->hdc_egl_temp should *not* be destroyed here! It is destroyed at dispose()! */
display_win32->hdc_egl_temp = hdc;
#endif
API: gdk: Remove gdk_window_get_visual() With it, remove window->visual.
2016-10-27 21:27:49 +00:00
if (!_gdk_win32_display_init_gl (display))
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("No GL implementation is available"));
return NULL;
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#if 0
if (display_win32->have_wgl)
{
hwnd = GDK_SURFACE_HWND (surface);
hdc = GetDC (hwnd);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
display_win32->gl_hwnd = hwnd;
}
#endif
#ifdef GDK_WIN32_ENABLE_EGL
if (display_win32->have_egl && !find_eglconfig_for_window (display_win32, &config,
&display_win32->egl_min_swap_interval, error))
return NULL;
#endif
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
context = g_object_new (GDK_TYPE_WIN32_GL_CONTEXT,
gdkglcontext-win32.c: Fix window->surface changes Rename the GdkSurface variables to surface, and make sure that we are creating the context GObject correctly. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-28 04:59:47 +00:00
"surface", surface,
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
"shared-context", share,
NULL);
context->gl_hdc = hdc;
context->is_attached = attached;
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
if (display_win32->have_egl)
context->egl_config = config;
#endif
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
return GDK_GL_CONTEXT (context);
}
gboolean
_gdk_win32_display_make_gl_context_current (GdkDisplay *display,
GdkGLContext *context)
{
GdkWin32GLContext *context_win32;
GdkWin32Display *display_win32 = GDK_WIN32_DISPLAY (display);
gdkglcontext-win32.c: Fix window->surface changes Rename the GdkSurface variables to surface, and make sure that we are creating the context GObject correctly. https://bugzilla.gnome.org/show_bug.cgi?id=773299
2018-03-28 04:59:47 +00:00
GdkSurface *surface;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
gboolean do_frame_sync = FALSE;
if (context == NULL)
{
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
if (display_win32->egl_disp != EGL_NO_DISPLAY)
eglMakeCurrent(display_win32->egl_disp,
EGL_NO_SURFACE,
EGL_NO_SURFACE,
EGL_NO_CONTEXT);
else
#endif
wglMakeCurrent(NULL, NULL);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
return TRUE;
}
context_win32 = GDK_WIN32_GL_CONTEXT (context);
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (!gdk_gl_context_get_use_es (context))
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (!wglMakeCurrent (context_win32->gl_hdc, context_win32->hglrc))
{
GDK_NOTE (OPENGL,
g_print ("Making WGL context current failed\n"));
return FALSE;
}
if (context_win32->is_attached && display_win32->hasWglEXTSwapControl)
{
surface = gdk_gl_context_get_surface (context);
/* 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. */
display = gdk_surface_get_display (surface);
do_frame_sync = ! gdk_display_is_composited (display);
if (do_frame_sync != context_win32->do_frame_sync)
{
context_win32->do_frame_sync = do_frame_sync;
if (do_frame_sync)
wglSwapIntervalEXT (1);
else
wglSwapIntervalEXT (0);
}
}
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#ifdef GDK_WIN32_ENABLE_EGL
else
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
EGLSurface egl_surface;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
surface = gdk_gl_context_get_surface (context);
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (context_win32->is_attached)
egl_surface = _gdk_win32_surface_get_egl_surface (surface, context_win32->egl_config, FALSE);
else
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (display_win32->hasEglSurfacelessContext)
egl_surface = EGL_NO_SURFACE;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
else
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
egl_surface = _gdk_win32_surface_get_egl_surface (surface, context_win32->egl_config, TRUE);
}
if (!eglMakeCurrent (display_win32->egl_disp,
egl_surface,
egl_surface,
context_win32->egl_context))
{
g_warning ("eglMakeCurrent failed");
return FALSE;
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
if (display_win32->egl_min_swap_interval == 0)
eglSwapInterval (display_win32->egl_disp, 0);
else
g_debug ("Can't disable GL swap interval");
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
#endif
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
return TRUE;
}
/**
* gdk_win32_display_get_wgl_version:
gdk: Clean up docs syntax Replace leftover gtk-doc syntax (#Type) with backquotes.
2021-05-20 03:39:18 +00:00
* @display: a `GdkDisplay`
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
* @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,
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int *major,
int *minor)
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
{
g_return_val_if_fail (GDK_IS_DISPLAY (display), FALSE);
if (!GDK_IS_WIN32_DISPLAY (display))
return FALSE;
API: gdk: Remove gdk_window_get_visual() With it, remove window->visual.
2016-10-27 21:27:49 +00:00
if (!_gdk_win32_display_init_gl (display))
Add OpenGL Support for the GDK Windows Backend This adds support for OpenGL to the GDK Windows backend using the WGL API calls, which enables programs that uses the GTK+ GLArea widgets to work on Windows as well. This also adds a simple utility function to query for the version of OpenGL that is supported by the Windows system, like the one provided by the X11 backend. Many thanks to Alex (and Emmanuele, who started the OpenGL integration in GTK+) who offered advice and help along the way, as well as the X11 and Wayland backend for this work to refer to and to model upon. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 04:32:04 +00:00
return FALSE;
if (major != NULL)
*major = GDK_WIN32_DISPLAY (display)->gl_version / 10;
if (minor != NULL)
*minor = GDK_WIN32_DISPLAY (display)->gl_version % 10;
return TRUE;
}
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
void
_gdk_win32_surface_invalidate_egl_framebuffer (GdkSurface *surface)
{
/* If we are using ANGLE, we need to force redraw of the whole Window and its child windows
* as we need to re-acquire the EGL surfaces that we rendered to upload to Cairo explicitly,
* using gdk_window_invalidate_rect (), when we maximize or restore or use aerosnap
*/
#ifdef GDK_WIN32_ENABLE_EGL
if (surface->gl_paint_context != NULL && gdk_gl_context_get_use_es (surface->gl_paint_context))
{
GdkWin32Surface *impl = GDK_WIN32_SURFACE (surface);
impl->egl_force_redraw_all = TRUE;
}
#endif
}
Reference in New Issue Copy Permalink