AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-12-28 06:21:14 +00:00
Code Issues Projects Releases Wiki Activity
430b6f8fb1
gtk/gdk/x11/gdkglcontext-x11.c

148 lines
4.3 KiB
C
Raw Normal View History

gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
/* GDK - The GIMP Drawing Kit
*
* gdkglcontext-x11.c: X11 specific OpenGL wrappers
*
* Copyright © 2014 Emmanuele Bassi
*
* 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 "gdkglcontext-x11.h"
#include "gdkdisplay-x11.h"
API: gdk: Remove gdk_window_get_visual() With it, remove window->visual.
2016-10-27 21:27:49 +00:00
#include "gdkprivate-x11.h"
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
#include "gdkscreen-x11.h"
#include "gdkx11display.h"
#include "gdkx11glcontext.h"
#include "gdkx11screen.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 "gdkx11surface.h"
Cache default gdk visuals in the GDK_VISUALS property on the root window This means we don't have to try to initialize opengl in every gtk instance that is stated. It will only happen for the first one. https://bugzilla.gnome.org/show_bug.cgi?id=738670
2014-10-29 12:33:08 +00:00
#include "gdkx11property.h"
#include <X11/Xatom.h>
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
#include "gdkinternals.h"
#include "gdkintl.h"
gdkglcontext-x11: Don't assume that cairo-xlib.h is in cairo directory If cairo is a subproject, it's not necessarily installed when gtk is built. In the source tree, cairo's headers are not stored in a directory called 'cairo'.
2021-03-16 08:51:40 +00:00
#include <cairo-xlib.h>
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
gdkglcontext-x11: Use epoxy/glx.h rather then GL/glx.h
2014-10-22 18:37:58 +00:00
#include <epoxy/glx.h>
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
x11: Decouple GLX from GdkX11GLContext If we want to add an EGL implementation for the X11 backend, we are going to need to move the GLX bits into their own class. The first step is to declare GdkX11GLContext as an abstract type, and then subclass it into a GdkX11GLContextGLX type, which includes the whole GLX implementation.
2021-05-10 14:07:08 +00:00
G_DEFINE_ABSTRACT_TYPE (GdkX11GLContext, gdk_x11_gl_context, GDK_TYPE_GL_CONTEXT)
x11: Create legacy GLX contexts If GLX has support for the GLX_ARB_create_context_profile extension, then we use the GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB; if it does not, we fall back to the old glXCreateNewContext() API. We use the shared GdkGLContext to decide whether the GLX context should use the legacy bit or not. https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-06 17:59:35 +00:00
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
static void
gdk_x11_gl_context_class_init (GdkX11GLContextClass *klass)
{
}
static void
gdk_x11_gl_context_init (GdkX11GLContext *self)
{
GdkGLContextX11: Only set swap interval when it changed
2014-11-05 11:02:18 +00:00
self->do_frame_sync = TRUE;
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
}
GdkGLContext *
GdkSurface: Rename lots of stuff from window->surface Mostly these are internal things, but the major public change is that event.window is now event.surface.
2018-03-20 14:14:10 +00:00
gdk_x11_surface_create_gl_context (GdkSurface *surface,
x11: Decouple GLX from GdkX11GLContext If we want to add an EGL implementation for the X11 backend, we are going to need to move the GLX bits into their own class. The first step is to declare GdkX11GLContext as an abstract type, and then subclass it into a GdkX11GLContextGLX type, which includes the whole GLX implementation.
2021-05-10 14:07:08 +00:00
gboolean attached,
GdkGLContext *share,
GError **error)
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
{
x11: Use EGL for GL support This makes the X11 backend similar to the Wayland one, when it comes to OpenGL. Fall back to GLX only if EGL support is not available.
2021-05-10 17:11:05 +00:00
GdkX11GLContext *context = NULL;
x11: Decouple GLX from GdkX11GLContext If we want to add an EGL implementation for the X11 backend, we are going to need to move the GLX bits into their own class. The first step is to declare GdkX11GLContext as an abstract type, and then subclass it into a GdkX11GLContextGLX type, which includes the whole GLX implementation.
2021-05-10 14:07:08 +00:00
GdkX11Display *display_x11;
GdkDisplay *display;
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
GdkSurface: Rename lots of stuff from window->surface Mostly these are internal things, but the major public change is that event.window is now event.surface.
2018-03-20 14:14:10 +00:00
display = gdk_surface_get_display (surface);
x11: Initialize GL at startup We need to initialize GL to select the Visual we are going to use for all our Windows. As the Visual needs to be known before we know if we are even gonna use GL later, we can't avoid initializing it. Note that this previously happened, too. It was just hidden behind the GdkScreen initialization.
2021-06-06 15:07:05 +00:00
display_x11 = GDK_X11_DISPLAY (display);
gl: Make all user GdkGLContexts not attached to any window We make user facing gl contexts not attached to a surface if possible, or attached to dummy surfaces. This means nothing can accidentally read/write to the toplevel back buffer.
2014-10-09 14:09:05 +00:00
x11: Move the EGL display into the private struct There's no need to use g_object_set_data() for it. We can also stop caching it elsewhere because we know the display has it. And finally, we can remove the display->have_egl boolean and use display->egl_display != NULL instead. We initialize the display at startup, so that variable is the perfect indicator.
2021-06-07 12:30:29 +00:00
if (display_x11->egl_display)
x11: Initialize GL at startup We need to initialize GL to select the Visual we are going to use for all our Windows. As the Visual needs to be known before we know if we are even gonna use GL later, we can't avoid initializing it. Note that this previously happened, too. It was just hidden behind the GdkScreen initialization.
2021-06-06 15:07:05 +00:00
context = gdk_x11_gl_context_egl_new (surface, attached, share, error);
x11: Use single GLX fbconfig and store it in the display This mirrors the code for the EGL config.
2021-06-29 20:10:48 +00:00
else if (display_x11->glx_config != NULL)
x11: Initialize GL at startup We need to initialize GL to select the Visual we are going to use for all our Windows. As the Visual needs to be known before we know if we are even gonna use GL later, we can't avoid initializing it. Note that this previously happened, too. It was just hidden behind the GdkScreen initialization.
2021-06-06 15:07:05 +00:00
context = gdk_x11_gl_context_glx_new (surface, attached, share, error);
else
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
{
x11: Properly record the error when initializing GL That way, we can give a useful error message when things break down for users. These error messages could still be improved in places (like looking at the actual EGL error codes), but that seemed overkill.
2021-07-02 01:21:14 +00:00
g_assert (display_x11->gl_error);
if (error)
*error = g_error_copy (display_x11->gl_error);
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
return NULL;
}
x11: Decouple GLX from GdkX11GLContext If we want to add an EGL implementation for the X11 backend, we are going to need to move the GLX bits into their own class. The first step is to declare GdkX11GLContext as an abstract type, and then subclass it into a GdkX11GLContextGLX type, which includes the whole GLX implementation.
2021-05-10 14:07:08 +00:00
if (context == NULL)
return NULL;
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
gl: Make all user GdkGLContexts not attached to any window We make user facing gl contexts not attached to a surface if possible, or attached to dummy surfaces. This means nothing can accidentally read/write to the toplevel back buffer.
2014-10-09 14:09:05 +00:00
context->is_attached = attached;
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
return GDK_GL_CONTEXT (context);
}
GdkGLContext: Change the way we track the current context To properly support multithreaded use we use a global GPrivate to track the current context. Since we also don't need to track the current context on the display we move gdk_display_destroy_gl_context to GdkGLContext::discard.
2014-10-30 10:46:09 +00:00
gboolean
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
gdk_x11_display_make_gl_context_current (GdkDisplay *display,
GdkGLContext *context)
{
x11: Decouple GLX from GdkX11GLContext If we want to add an EGL implementation for the X11 backend, we are going to need to move the GLX bits into their own class. The first step is to declare GdkX11GLContext as an abstract type, and then subclass it into a GdkX11GLContextGLX type, which includes the whole GLX implementation.
2021-05-10 14:07:08 +00:00
GdkX11Display *display_x11 = GDK_X11_DISPLAY (display);
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
x11: Move the EGL display into the private struct There's no need to use g_object_set_data() for it. We can also stop caching it elsewhere because we know the display has it. And finally, we can remove the display->have_egl boolean and use display->egl_display != NULL instead. We initialize the display at startup, so that variable is the perfect indicator.
2021-06-07 12:30:29 +00:00
if (display_x11->egl_display)
x11: Use EGL for GL support This makes the X11 backend similar to the Wayland one, when it comes to OpenGL. Fall back to GLX only if EGL support is not available.
2021-05-10 17:11:05 +00:00
return gdk_x11_gl_context_egl_make_current (display, context);
x11: Use single GLX fbconfig and store it in the display This mirrors the code for the EGL config.
2021-06-29 20:10:48 +00:00
else if (display_x11->glx_config)
x11: Decouple GLX from GdkX11GLContext If we want to add an EGL implementation for the X11 backend, we are going to need to move the GLX bits into their own class. The first step is to declare GdkX11GLContext as an abstract type, and then subclass it into a GdkX11GLContextGLX type, which includes the whole GLX implementation.
2021-05-10 14:07:08 +00:00
return gdk_x11_gl_context_glx_make_current (display, context);
x11: Use EGL for GL support This makes the X11 backend similar to the Wayland one, when it comes to OpenGL. Fall back to GLX only if EGL support is not available.
2021-05-10 17:11:05 +00:00
else
g_assert_not_reached ();
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
x11: Decouple GLX from GdkX11GLContext If we want to add an EGL implementation for the X11 backend, we are going to need to move the GLX bits into their own class. The first step is to declare GdkX11GLContext as an abstract type, and then subclass it into a GdkX11GLContextGLX type, which includes the whole GLX implementation.
2021-05-10 14:07:08 +00:00
return FALSE;
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
}
x11: Move GL init code into the GL context No functional changes, just shuffling code.
2021-06-12 09:07:24 +00:00
x11: Rework Visual selection Instead of going via GdkVisual, doing a preselection and letting the GL initialization improve it, let the GL initialization pick an X Visual directly using X Visual code directly. The code should select the same visuals as before as it tries to apply the same logic, but it's a rewrite, so I expect I messed something up.
2021-06-13 15:34:55 +00:00
gboolean
gdk: Add GdkDisplay::init_gl vfunc The vfunc is called to initialize GL and it returns a "base" context that GDK then uses as the context all others are shared with. So the GL context share tree now looks like: + context from init_gl - context1 - context2 ... So this is a flat tree now, the complexity is gone. The only caveat is that backends now need to create a GL context when initializing GL so some refactoring was needed. Two new functions have been added: * gdk_display_prepare_gl() This is public API and can be used to ensure that GL has been initialized or if not, retrieve an error to display (or debug-print). * gdk_display_get_gl_context() This is a private function to retrieve the base context from init_gl(). It replaces gdk_surface_get_shared_data_context().
2021-07-04 23:57:03 +00:00
gdk_x11_display_init_gl_backend (GdkX11Display *self,
Visual **out_visual,
int *out_depth,
GError **error)
x11: Move GL init code into the GL context No functional changes, just shuffling code.
2021-06-12 09:07:24 +00:00
{
GdkDisplay *display G_GNUC_UNUSED = GDK_DISPLAY (self);
if (GDK_DISPLAY_DEBUG_CHECK (display, GL_DISABLE))
x11: Properly record the error when initializing GL That way, we can give a useful error message when things break down for users. These error messages could still be improved in places (like looking at the actual EGL error codes), but that seemed overkill.
2021-07-02 01:21:14 +00:00
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("GL support disabled via GDK_DEBUG=gl-disable"));
return FALSE;
}
x11: Move GL init code into the GL context No functional changes, just shuffling code.
2021-06-12 09:07:24 +00:00
x11: Redo choice between EGL and GLX We try EGL first, but are very picky about what we accept. If that fails, we try to go with GLX instead. And if that also fails, we try EGL again, but this time accept anything. The idea here is that EGL is the preferred method going forward, but GLX is the tried and tested method that we know works. So if we detect issues with EGL, we want to avoid using it in favor of GLX. Also add a GDK_DEBUG=gl-egl option to force EGL at all costs and not try GLX.
2021-07-02 01:37:32 +00:00
if (GDK_DISPLAY_DEBUG_CHECK (display, GL_EGL))
return gdk_x11_display_init_egl (self, TRUE, out_visual, out_depth, error);
if (GDK_DISPLAY_DEBUG_CHECK (display, GL_GLX))
return gdk_x11_display_init_glx (self, out_visual, out_depth, error);
/* No env vars set, do the regular GL initialization.
*
* We try EGL first, but are very picky about what we accept.
* If that fails, we try to go with GLX instead.
* And if that also fails, we try EGL again, but this time accept anything.
*
* The idea here is that EGL is the preferred method going forward, but GLX is
* the tried and tested method that we know works. So if we detect issues with
* EGL, we want to avoid using it in favor of GLX.
*/
if (gdk_x11_display_init_egl (self, FALSE, out_visual, out_depth, error))
return TRUE;
g_clear_error (error);
if (gdk_x11_display_init_glx (self, out_visual, out_depth, error))
return TRUE;
g_clear_error (error);
return gdk_x11_display_init_egl (self, TRUE, out_visual, out_depth, error);
x11: Move GL init code into the GL context No functional changes, just shuffling code.
2021-06-12 09:07:24 +00:00
}
Reference in New Issue Copy Permalink