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

1292 lines
41 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"
Drop GdkVisual This type was unused except for serving as a parent for GdkX11Visual. Just move the fields to that type.
2017-11-01 02:44:15 +00:00
#include "gdkvisual-x11.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
G_DEFINE_TYPE (GdkX11GLContext, gdk_x11_gl_context, GDK_TYPE_GL_CONTEXT)
typedef struct {
GdkDisplay *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
GLXDrawable glx_drawable;
Window dummy_xwin;
GLXWindow dummy_glx;
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
guint32 last_frame_counter;
} DrawableInfo;
static void
drawable_info_free (gpointer data_)
{
DrawableInfo *data = data_;
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
Display *dpy;
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_error_trap_push (data->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
dpy = gdk_x11_display_get_xdisplay (data->display);
if (data->glx_drawable)
glXDestroyWindow (dpy, data->glx_drawable);
if (data->dummy_glx)
glXDestroyWindow (dpy, data->dummy_glx);
if (data->dummy_xwin)
XDestroyWindow (dpy, data->dummy_xwin);
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_error_trap_pop_ignored (data->display);
g_slice_free (DrawableInfo, data);
}
static DrawableInfo *
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
get_glx_drawable_info (GdkSurface *surface)
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
return g_object_get_data (G_OBJECT (surface), "-gdk-x11-surface-glx-info");
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
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
set_glx_drawable_info (GdkSurface *surface,
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
DrawableInfo *info)
{
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
g_object_set_data_full (G_OBJECT (surface), "-gdk-x11-surface-glx-info",
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
info,
drawable_info_free);
}
static void
maybe_wait_for_vblank (GdkDisplay *display,
GLXDrawable drawable)
{
GdkX11Display *display_x11 = GDK_X11_DISPLAY (display);
Display *dpy = gdk_x11_display_get_xdisplay (display);
if (display_x11->has_glx_sync_control)
{
gint64 ust, msc, sbc;
glXGetSyncValuesOML (dpy, drawable, &ust, &msc, &sbc);
glXWaitForMscOML (dpy, drawable,
0, 2, (msc + 1) % 2,
&ust, &msc, &sbc);
}
else if (display_x11->has_glx_video_sync)
{
guint32 current_count;
glXGetVideoSyncSGI (&current_count);
glXWaitVideoSyncSGI (2, (current_count + 1) % 2, &current_count);
}
}
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_x11_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)
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: 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);
GdkX11GLContext *context_x11 = GDK_X11_GL_CONTEXT (context);
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
GdkSurface *surface = gdk_gl_context_get_surface (context);
GdkGLContext: Add display property We need to use this in the code path where we make the context non-current during destroy, because at that point the window could be destroyed and gdk_window_get_display() would return NULL.
2014-11-03 12:20:55 +00:00
GdkDisplay *display = gdk_gl_context_get_display (context);
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
Display *dpy = gdk_x11_display_get_xdisplay (display);
GdkX11Display *display_x11 = GDK_X11_DISPLAY (display);
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
//GdkRectangle whole_window;
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
DrawableInfo *info;
GLXDrawable drawable;
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_x11_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;
gdk_gl_context_make_current (context);
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
info = get_glx_drawable_info (surface);
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: 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
drawable = context_x11->attached_drawable;
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
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL,
x11: Don't use g_print for debug output The g_print documentation explicitly says not to do this, since g_print is meant to be redirected by applications. Instead use g_message for logging that can be triggered via GTK_DEBUG.
2016-02-29 02:29:16 +00:00
g_message ("Flushing GLX buffers for drawable %lu (window: %lu), frame sync: %s",
(unsigned long) drawable,
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
(unsigned long) gdk_x11_surface_get_xid (surface),
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
context_x11->do_frame_sync ? "yes" : "no"));
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
/* if we are going to wait for the vertical refresh manually
* we need to flush pending redraws, and we also need to wait
* for that to finish, otherwise we are going to tear.
*
* obviously, this condition should not be hit if we have
* GLX_SGI_swap_control, and we ask the driver to do the right
* thing.
*/
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 (context_x11->do_frame_sync)
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
{
guint32 end_frame_counter = 0;
gboolean has_counter = display_x11->has_glx_video_sync;
gboolean can_wait = display_x11->has_glx_video_sync || display_x11->has_glx_sync_control;
if (display_x11->has_glx_video_sync)
glXGetVideoSyncSGI (&end_frame_counter);
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 (context_x11->do_frame_sync && !display_x11->has_glx_swap_interval)
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
{
glFinish ();
if (has_counter && can_wait)
{
guint32 last_counter = info != NULL ? info->last_frame_counter : 0;
if (last_counter == end_frame_counter)
maybe_wait_for_vblank (display, drawable);
}
else if (can_wait)
maybe_wait_for_vblank (display, drawable);
}
}
x11: Make the frame clock work in GL and Vulkan
2018-03-30 08:43:26 +00:00
gdk_x11_surface_pre_damage (surface);
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
#ifdef HAVE_XDAMAGE
x11: Don't set up frame sync fence on unsupported compositors Not all compositors support _NET_WM_FRAME_DRAWN. In cases where the compositor doesn't support _NET_WM_FRAME_DRAWN we don't need to do all the fancy damage tracking and fence watching. Furthermore, if the compositor doesn't support _NET_WM_FRAME_DRAWN, it's possible that one frame will start before the previous frame has made it through the pipeline, leading to a blown assertion. This commit side-steps the unnecessary code and associated assertion when _NET_WM_FRAME_DRAWN isn't supported. Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2927
2020-07-14 13:40:34 +00:00
if (context_x11->xdamage != 0 && _gdk_x11_surface_syncs_frames (surface))
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
{
g_assert (context_x11->frame_fence == 0);
context_x11->frame_fence = glFenceSync (GL_SYNC_GPU_COMMANDS_COMPLETE, 0);
/* We consider the frame still getting painted until the GL operation is
* finished, and the window gets damage reported from the X server.
* It's only at this point the compositor can be sure it has full
* access to the new updates.
*/
_gdk_x11_surface_set_frame_still_painting (surface, TRUE);
}
#endif
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
glXSwapBuffers (dpy, drawable);
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: 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 (context_x11->do_frame_sync && info != NULL && display_x11->has_glx_video_sync)
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
glXGetVideoSyncSGI (&info->last_frame_counter);
}
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
static cairo_region_t *
gdk_x11_gl_context_get_damage (GdkGLContext *context)
{
GdkDisplay *display = gdk_draw_context_get_display (GDK_DRAW_CONTEXT (context));
GdkX11Display *display_x11 = GDK_X11_DISPLAY (display);
Display *dpy = gdk_x11_display_get_xdisplay (display);
unsigned int buffer_age = 0;
if (display_x11->has_glx_buffer_age)
{
GdkGLContext *shared;
GdkX11GLContext *shared_x11;
GdkGLContext: Fix damage computation with buffer_age As per the spec: > The back buffer can > either be reported as invalid (has an age of 0) or it may be > reported to contain the contents from n frames prior to the > current frame. So a buffer age of 1 means that the buffer was used in the last frame. We were handling buffer_age==1 the same as buffer_age==0, i.e. we returned the full damage for the surface. [1] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_buffer_age.txt
2018-11-30 12:14:00 +00:00
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
shared = gdk_gl_context_get_shared_context (context);
if (shared == NULL)
shared = context;
shared_x11 = GDK_X11_GL_CONTEXT (shared);
gdk_gl_context_make_current (shared);
GdkGLContext: Fix damage computation with buffer_age As per the spec: > The back buffer can > either be reported as invalid (has an age of 0) or it may be > reported to contain the contents from n frames prior to the > current frame. So a buffer age of 1 means that the buffer was used in the last frame. We were handling buffer_age==1 the same as buffer_age==0, i.e. we returned the full damage for the surface. [1] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_buffer_age.txt
2018-11-30 12:14:00 +00:00
glXQueryDrawable (dpy, shared_x11->attached_drawable,
GLX_BACK_BUFFER_AGE_EXT, &buffer_age);
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
GdkGLContext: Fix damage computation with buffer_age As per the spec: > The back buffer can > either be reported as invalid (has an age of 0) or it may be > reported to contain the contents from n frames prior to the > current frame. So a buffer age of 1 means that the buffer was used in the last frame. We were handling buffer_age==1 the same as buffer_age==0, i.e. we returned the full damage for the surface. [1] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_buffer_age.txt
2018-11-30 12:14:00 +00:00
switch (buffer_age)
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
{
GdkGLContext: Fix damage computation with buffer_age As per the spec: > The back buffer can > either be reported as invalid (has an age of 0) or it may be > reported to contain the contents from n frames prior to the > current frame. So a buffer age of 1 means that the buffer was used in the last frame. We were handling buffer_age==1 the same as buffer_age==0, i.e. we returned the full damage for the surface. [1] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_buffer_age.txt
2018-11-30 12:14:00 +00:00
case 1:
return cairo_region_create ();
break;
case 2:
if (context->old_updated_area[0])
return cairo_region_copy (context->old_updated_area[0]);
break;
case 3:
if (context->old_updated_area[0] &&
context->old_updated_area[1])
{
cairo_region_t *damage = cairo_region_copy (context->old_updated_area[0]);
cairo_region_union (damage, context->old_updated_area[1]);
return damage;
}
break;
default:
;
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
}
GdkGLContext: Fix damage computation with buffer_age As per the spec: > The back buffer can > either be reported as invalid (has an age of 0) or it may be > reported to contain the contents from n frames prior to the > current frame. So a buffer age of 1 means that the buffer was used in the last frame. We were handling buffer_age==1 the same as buffer_age==0, i.e. we returned the full damage for the surface. [1] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_buffer_age.txt
2018-11-30 12:14:00 +00:00
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
}
return GDK_GL_CONTEXT_CLASS (gdk_x11_gl_context_parent_class)->get_damage (context);
}
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
static XVisualInfo *
find_xvisinfo_for_fbconfig (GdkDisplay *display,
GLXFBConfig config)
{
Display *dpy = gdk_x11_display_get_xdisplay (display);
return glXGetVisualFromFBConfig (dpy, config);
}
static GLXContext
create_gl3_context (GdkDisplay *display,
GLXFBConfig config,
x11/gl: Use the GdkGLContext options When creating an OpenGL context using the glXCreateContextAttribs() function. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:40:34 +00:00
GdkGLContext *share,
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
int profile,
x11/gl: Use the GdkGLContext options When creating an OpenGL context using the glXCreateContextAttribs() function. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:40:34 +00:00
int flags,
int major,
int minor)
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
{
x11/gl: Use the GdkGLContext options When creating an OpenGL context using the glXCreateContextAttribs() function. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:40:34 +00:00
int attrib_list[] = {
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
GLX_CONTEXT_PROFILE_MASK_ARB, profile,
x11/gl: Use the GdkGLContext options When creating an OpenGL context using the glXCreateContextAttribs() function. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:40:34 +00:00
GLX_CONTEXT_MAJOR_VERSION_ARB, major,
GLX_CONTEXT_MINOR_VERSION_ARB, minor,
GLX_CONTEXT_FLAGS_ARB, flags,
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
None,
};
x11/gl: Trap GL context creation Avoid an X11 error in case the context creation fails, so we can avoid a crash and pick it up in the upper layers, and display an error. https://bugzilla.gnome.org/show_bug.cgi?id=746746
2015-03-25 14:34:42 +00:00
GLXContext res;
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
x11/gl: Use the GdkGLContext options When creating an OpenGL context using the glXCreateContextAttribs() function. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:40:34 +00:00
GdkX11GLContext *share_x11 = NULL;
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
if (share != NULL)
x11/gl: Use the GdkGLContext options When creating an OpenGL context using the glXCreateContextAttribs() function. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:40:34 +00:00
share_x11 = GDK_X11_GL_CONTEXT (share);
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
x11/gl: Trap GL context creation Avoid an X11 error in case the context creation fails, so we can avoid a crash and pick it up in the upper layers, and display an error. https://bugzilla.gnome.org/show_bug.cgi?id=746746
2015-03-25 14:34:42 +00:00
gdk_x11_display_error_trap_push (display);
res = glXCreateContextAttribsARB (gdk_x11_display_get_xdisplay (display),
config,
share_x11 != NULL ? share_x11->glx_context : NULL,
True,
attrib_list);
if (gdk_x11_display_error_trap_pop (display))
return NULL;
return res;
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
}
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
static GLXContext
create_legacy_context (GdkDisplay *display,
GLXFBConfig config,
GdkGLContext *share)
{
GdkX11GLContext *share_x11 = NULL;
GLXContext res;
if (share != NULL)
share_x11 = GDK_X11_GL_CONTEXT (share);
gdk_x11_display_error_trap_push (display);
res = glXCreateNewContext (gdk_x11_display_get_xdisplay (display),
config,
GLX_RGBA_TYPE,
share_x11 != NULL ? share_x11->glx_context : NULL,
TRUE);
if (gdk_x11_display_error_trap_pop (display))
return NULL;
return res;
}
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
#ifdef HAVE_XDAMAGE
x11: Handle window getting unmapped while frame still pending Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync for the vendor nvidia driver, to know when a frame is ready for the compositor to process. If a surface is hidden while a frame is still being rendered by the GPU, the surface will never produce the damage event the code relies on to trigger the call to glClientWaitSync. This leaves the fence dangling, and the next time the surface is shown, it will start a fresh frame and blow an assertion since the fence from the last frame is still hanging around. This commit ensures a frame gets fully wrapped up before hiding a surface.
2020-06-29 14:21:58 +00:00
static void
finish_frame (GdkGLContext *context)
{
GdkX11GLContext *context_x11 = GDK_X11_GL_CONTEXT (context);
GdkSurface *surface = gdk_gl_context_get_surface (context);
if (context_x11->xdamage == 0)
return;
if (context_x11->frame_fence == 0)
return;
glDeleteSync (context_x11->frame_fence);
context_x11->frame_fence = 0;
_gdk_x11_surface_set_frame_still_painting (surface, FALSE);
}
x11: Ensure bound context is compatible with sync fence Commit a0f6ff101e781aaf0a931be6e22f2885f4f69e04 made sure that a context was bound before calling glClientWaitSync, but it doesn't check that the context shares objects with the context that created the fence. This commit does a little more validation before deciding the current context is good enough.
2020-06-22 21:13:54 +00:00
static void
bind_context_for_frame_fence (GdkGLContext *context)
{
GdkGLContext *current_context;
GdkX11GLContext *current_context_x11;
GLXContext current_glx_context = NULL;
gboolean needs_binding = TRUE;
/* We don't care if the passed context is the current context,
* necessarily, but we do care that *some* context that can
* see the sync object is bound.
*
* If no context is bound at all, the GL dispatch layer will
* make glClientWaitSync() silently return 0.
*/
current_glx_context = glXGetCurrentContext ();
if (current_glx_context == NULL)
goto out;
current_context = gdk_gl_context_get_current ();
if (current_context == NULL)
goto out;
current_context_x11 = GDK_X11_GL_CONTEXT (current_context);
/* If the GLX context was changed out from under GDK, then
* that context may not be one that is able to see the
* created fence object.
*/
if (current_context_x11->glx_context != current_glx_context)
goto out;
needs_binding = FALSE;
out:
if (needs_binding)
gdk_gl_context_make_current (context);
}
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
static gboolean
on_gl_surface_xevent (GdkGLContext *context,
XEvent *xevent,
GdkX11Display *display_x11)
{
GdkX11GLContext *context_x11 = GDK_X11_GL_CONTEXT (context);
XDamageNotifyEvent *damage_xevent;
if (!context_x11->is_attached)
return FALSE;
if (xevent->type != (display_x11->damage_event_base + XDamageNotify))
return FALSE;
damage_xevent = (XDamageNotifyEvent *) xevent;
if (damage_xevent->damage != context_x11->xdamage)
return FALSE;
if (context_x11->frame_fence)
{
GLenum wait_result;
x11: Ensure bound context is compatible with sync fence Commit a0f6ff101e781aaf0a931be6e22f2885f4f69e04 made sure that a context was bound before calling glClientWaitSync, but it doesn't check that the context shares objects with the context that created the fence. This commit does a little more validation before deciding the current context is good enough.
2020-06-22 21:13:54 +00:00
bind_context_for_frame_fence (context);
x11: ensure some context is bound before calling glClientWaitSync Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync for the vendor nvidia driver, to know when a frame is ready for the compositor to process. glClientWaitSync can be called regardless of which context is currently bound, but if no context is bound at all, it returns 0 without doing anything. This commit checks for that edge case, and ensures a context gets made current in the event no context is already current, before calling glClientWaitSync.
2020-06-22 21:13:54 +00:00
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
wait_result = glClientWaitSync (context_x11->frame_fence, 0, 0);
switch (wait_result)
{
/* We assume that if the fence has been signaled, that this damage
* event is the damage event that was triggered by the GL drawing
* associated with the fence. That's, technically, not necessarly
* always true. The X server could have generated damage for
* an unrelated event (say the size of the window changing), at
* just the right moment such that we're picking it up instead.
*
* We're choosing not to handle this edge case, but if it does ever
* happen in the wild, it could lead to slight underdrawing by
* the compositor for one frame. In the future, if we find out
* this edge case is noticeable, we can compensate by copying the
* painted region from gdk_x11_gl_context_end_frame and subtracting
* damaged areas from the copy as they come in. Once the copied
* region goes empty, we know that there won't be any underdraw,
* and can mark painting has finished. It's not worth the added
* complexity and resource usage to do this bookkeeping, however,
* unless the problem is practically visible.
*/
case GL_ALREADY_SIGNALED:
case GL_CONDITION_SATISFIED:
case GL_WAIT_FAILED:
if (wait_result == GL_WAIT_FAILED)
g_warning ("failed to wait on GL fence associated with last swap buffers call");
x11: Handle window getting unmapped while frame still pending Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync for the vendor nvidia driver, to know when a frame is ready for the compositor to process. If a surface is hidden while a frame is still being rendered by the GPU, the surface will never produce the damage event the code relies on to trigger the call to glClientWaitSync. This leaves the fence dangling, and the next time the surface is shown, it will start a fresh frame and blow an assertion since the fence from the last frame is still hanging around. This commit ensures a frame gets fully wrapped up before hiding a surface.
2020-06-29 14:21:58 +00:00
finish_frame (context);
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
break;
/* We assume that if the fence hasn't been signaled, that this
* damage event is not the damage event that was triggered by the
* GL drawing associated with the fence. That's only true for
* the Nvidia vendor driver. When using open source drivers, damage
* is emitted immediately on swap buffers, before the fence ever
* has a chance to signal.
*/
case GL_TIMEOUT_EXPIRED:
break;
default:
x11: be more verbose when glClientWaitSync behaves unexpectedtly When given a 0 timeout, glClientWaitSync is only supposed to return one of three possible values: - GL_ALREADY_SIGNALED - fence fired - GL_WAIT_FAILED - there was an error - GL_TIMEOUT_EXPIRED - fence hasn't fired yet In addition, it can also return GL_CONDITION_SATISFIED if a non-zero timeout is passed, and the fence fires while waiting on the timeout. Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync (with a 0 timeout), but one user is reporting it's returning some value that's not one of the above four. This commit changes the g_assert to a g_error so we can see what value is getting returned. May help with https://gitlab.gnome.org/GNOME/gtk/-/issues/2858
2020-06-22 15:07:32 +00:00
g_error ("glClientWaitSync returned unexpected result: %x", (guint) wait_result);
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
}
}
return FALSE;
}
x11: Handle window getting unmapped while frame still pending Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync for the vendor nvidia driver, to know when a frame is ready for the compositor to process. If a surface is hidden while a frame is still being rendered by the GPU, the surface will never produce the damage event the code relies on to trigger the call to glClientWaitSync. This leaves the fence dangling, and the next time the surface is shown, it will start a fresh frame and blow an assertion since the fence from the last frame is still hanging around. This commit ensures a frame gets fully wrapped up before hiding a surface.
2020-06-29 14:21:58 +00:00
static void
on_surface_state_changed (GdkGLContext *context)
{
GdkSurface *surface = gdk_gl_context_get_surface (context);
gdk: Replace 'WITHDRAWN' state with async 'is-mapped' boolean It was used by all surfaces to track 'is-mapped', but still part of the GdkToplevelState, and is now replaced with a separate boolean in the GdkSurface structure. It also caused issues when a widget was unmapped, and due to that unmapped a popover which hid its corresponding surface. When this surface was hidden, it emitted a state change event, which would then go back into GTK and queue a resize on popover widget, which would travel back down to the widget that was originally unmapped, causing confusino when doing future allocations. To summarize, one should not hide widgets during allocation, and to avoid this, make this new is-mapped boolean asynchronous when hiding a surface, meaning the notification event for the changed mapped state will be emitted in an idle callback. This avoids the above described reentry issue.
2020-12-07 17:18:38 +00:00
if (GDK_SURFACE_IS_MAPPED (surface))
x11: Handle window getting unmapped while frame still pending Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync for the vendor nvidia driver, to know when a frame is ready for the compositor to process. If a surface is hidden while a frame is still being rendered by the GPU, the surface will never produce the damage event the code relies on to trigger the call to glClientWaitSync. This leaves the fence dangling, and the next time the surface is shown, it will start a fresh frame and blow an assertion since the fence from the last frame is still hanging around. This commit ensures a frame gets fully wrapped up before hiding a surface.
2020-06-29 14:21:58 +00:00
return;
/* If we're about to withdraw the surface, then we don't care if the frame is
* still getting rendered by the GPU. The compositor is going to remove the surface
* from the scene anyway, so wrap up the frame.
*/
finish_frame (context);
}
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
#endif
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
static gboolean
gdk_x11_gl_context_realize (GdkGLContext *context,
GError **error)
{
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
GdkX11Display *display_x11;
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
GdkDisplay *display;
GdkX11GLContext *context_x11;
XVisualInfo *xvisinfo;
Display *dpy;
DrawableInfo *info;
GdkGLContext *share;
gdk: Create a global shared GL context Create a global GL context that connects all GL contexts on a display and lets us share textures between them.
2019-06-04 21:26:28 +00:00
GdkGLContext *shared_data_context;
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
GdkSurface *surface;
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
gboolean debug_bit, compat_bit, legacy_bit, es_bit;
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
int major, minor, flags;
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +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
surface = gdk_gl_context_get_surface (context);
display = gdk_surface_get_display (surface);
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
dpy = gdk_x11_display_get_xdisplay (display);
context_x11 = GDK_X11_GL_CONTEXT (context);
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
display_x11 = GDK_X11_DISPLAY (display);
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
share = gdk_gl_context_get_shared_context (context);
gdk: Create a global shared GL context Create a global GL context that connects all GL contexts on a display and lets us share textures between them.
2019-06-04 21:26:28 +00:00
shared_data_context = gdk_surface_get_shared_data_gl_context (surface);
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +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
gdk_gl_context_get_required_version (context, &major, &minor);
debug_bit = gdk_gl_context_get_debug_enabled (context);
compat_bit = gdk_gl_context_get_forward_compatible (context);
gl: Drop profile for gdk_window_create_gl_context() Now that we have a two-stages GL context creation sequence, we can move the profile to a pre-realize option, like the debug and forward compatibility bits, or the GL version to use.
2015-02-12 12:34:28 +00:00
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
/* If there is no glXCreateContextAttribsARB() then we default to legacy */
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
legacy_bit = !display_x11->has_glx_create_context || GDK_DISPLAY_DEBUG_CHECK (display, GL_LEGACY);
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
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
es_bit = (GDK_DISPLAY_DEBUG_CHECK (display, GL_GLES) || (share != NULL && gdk_gl_context_get_use_es (share))) &&
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
(display_x11->has_glx_create_context && display_x11->has_glx_create_es2_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
/* We cannot share legacy contexts with core profile ones, so the
* shared context is the one that decides if we're going to create
* a legacy context or not.
*/
if (share != NULL && gdk_gl_context_is_legacy (share))
legacy_bit = TRUE;
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
flags = 0;
if (debug_bit)
flags |= GLX_CONTEXT_DEBUG_BIT_ARB;
if (compat_bit)
flags |= GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB;
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL,
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
g_message ("Creating GLX context (version:%d.%d, debug:%s, forward:%s, legacy:%s, es:%s)",
x11: Don't use g_print for debug output The g_print documentation explicitly says not to do this, since g_print is meant to be redirected by applications. Instead use g_message for logging that can be triggered via GTK_DEBUG.
2016-02-29 02:29:16 +00:00
major, minor,
debug_bit ? "yes" : "no",
compat_bit ? "yes" : "no",
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
legacy_bit ? "yes" : "no",
es_bit ? "yes" : "no"));
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
/* If we have access to GLX_ARB_create_context_profile then we can ask for
* a compatibility profile; if we don't, then we have to fall back to the
* old GLX 1.3 API.
*/
if (legacy_bit && !GDK_X11_DISPLAY (display)->has_glx_create_context)
{
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL, g_message ("Creating legacy GL context on request"));
gdk: Create a global shared GL context Create a global GL context that connects all GL contexts on a display and lets us share textures between them.
2019-06-04 21:26:28 +00:00
context_x11->glx_context = create_legacy_context (display, context_x11->glx_config, share ? share : shared_data_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
}
else
{
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
int profile;
if (es_bit)
profile = GLX_CONTEXT_ES2_PROFILE_BIT_EXT;
else
profile = legacy_bit ? GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB
: GLX_CONTEXT_CORE_PROFILE_BIT_ARB;
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
/* We need to tweak the version, otherwise we may end up requesting
* a compatibility context with a minimum version of 3.2, which is
* an error
*/
if (legacy_bit)
{
major = 3;
minor = 0;
}
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL, g_message ("Creating GL3 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
context_x11->glx_context = create_gl3_context (display,
context_x11->glx_config,
gdk: Create a global shared GL context Create a global GL context that connects all GL contexts on a display and lets us share textures between them.
2019-06-04 21:26:28 +00:00
share ? share : shared_data_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
profile, flags, major, minor);
/* Fall back to legacy in case the GL3 context creation failed */
if (context_x11->glx_context == NULL)
{
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL, g_message ("Creating fallback legacy context"));
gdk: Create a global shared GL context Create a global GL context that connects all GL contexts on a display and lets us share textures between them.
2019-06-04 21:26:28 +00:00
context_x11->glx_context = create_legacy_context (display, context_x11->glx_config, share ? share : shared_data_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
legacy_bit = TRUE;
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
es_bit = FALSE;
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
}
}
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
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
if (context_x11->glx_context == NULL)
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("Unable to create a GL context"));
return FALSE;
}
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
/* Ensure that any other context is created with a legacy bit set */
gdk_gl_context_set_is_legacy (context, legacy_bit);
Minor typos in the Documentation (a/an)
2019-08-25 12:52:24 +00:00
/* Ensure that any other context is created with an ES bit set */
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
gdk_gl_context_set_use_es (context, es_bit);
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
xvisinfo = find_xvisinfo_for_fbconfig (display, context_x11->glx_config);
Get rid of GdkSurfaceImpl We don't need the complicated wrapper system anymore, since client-side windows are gone. This commit moves all the vfuncs to GtkSurfaceClass, and changes the backends to just derive their surface implementation from GdkSurface.
2019-04-22 01:14:46 +00:00
info = get_glx_drawable_info (surface);
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
if (info == NULL)
{
XSetWindowAttributes attrs;
unsigned long mask;
gdk_x11_display_error_trap_push (display);
info = g_slice_new0 (DrawableInfo);
info->display = display;
info->last_frame_counter = 0;
attrs.override_redirect = True;
attrs.colormap = XCreateColormap (dpy, DefaultRootWindow (dpy), xvisinfo->visual, AllocNone);
attrs.border_pixel = 0;
mask = CWOverrideRedirect | CWColormap | CWBorderPixel;
info->dummy_xwin = XCreateWindow (dpy, DefaultRootWindow (dpy),
-100, -100, 1, 1,
0,
xvisinfo->depth,
CopyFromParent,
xvisinfo->visual,
mask,
&attrs);
XMapWindow(dpy, info->dummy_xwin);
if (GDK_X11_DISPLAY (display)->glx_version >= 13)
{
info->glx_drawable = glXCreateWindow (dpy, context_x11->glx_config,
Get rid of GdkSurfaceImpl We don't need the complicated wrapper system anymore, since client-side windows are gone. This commit moves all the vfuncs to GtkSurfaceClass, and changes the backends to just derive their surface implementation from GdkSurface.
2019-04-22 01:14:46 +00:00
gdk_x11_surface_get_xid (surface),
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
NULL);
info->dummy_glx = glXCreateWindow (dpy, context_x11->glx_config, info->dummy_xwin, NULL);
}
if (gdk_x11_display_error_trap_pop (display))
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("Unable to create a GL context"));
XFree (xvisinfo);
drawable_info_free (info);
glXDestroyContext (dpy, context_x11->glx_context);
context_x11->glx_context = NULL;
return FALSE;
}
Get rid of GdkSurfaceImpl We don't need the complicated wrapper system anymore, since client-side windows are gone. This commit moves all the vfuncs to GtkSurfaceClass, and changes the backends to just derive their surface implementation from GdkSurface.
2019-04-22 01:14:46 +00:00
set_glx_drawable_info (surface, info);
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
}
XFree (xvisinfo);
Get rid of GdkSurfaceImpl We don't need the complicated wrapper system anymore, since client-side windows are gone. This commit moves all the vfuncs to GtkSurfaceClass, and changes the backends to just derive their surface implementation from GdkSurface.
2019-04-22 01:14:46 +00:00
context_x11->attached_drawable = info->glx_drawable ? info->glx_drawable : gdk_x11_surface_get_xid (surface);
glcontext: Make begin/end_draw() paired This way, we can query the GL context's state via gdk_gl_context_is_drawing(). Use this function to make GL contexts as attached and grant them access to the front/backbuffer for rendering. All of this is still unused because GL drawing is still disabled.
2016-11-23 04:18:43 +00:00
context_x11->unattached_drawable = info->dummy_glx ? info->dummy_glx : info->dummy_xwin;
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
#ifdef HAVE_XDAMAGE
if (display_x11->have_damage && display_x11->has_async_glx_swap_buffers)
{
gdk_x11_display_error_trap_push (display);
context_x11->xdamage = XDamageCreate (dpy,
gdk_x11_surface_get_xid (surface),
XDamageReportRawRectangles);
if (gdk_x11_display_error_trap_pop (display))
x11: Handle window getting unmapped while frame still pending Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync for the vendor nvidia driver, to know when a frame is ready for the compositor to process. If a surface is hidden while a frame is still being rendered by the GPU, the surface will never produce the damage event the code relies on to trigger the call to glClientWaitSync. This leaves the fence dangling, and the next time the surface is shown, it will start a fresh frame and blow an assertion since the fence from the last frame is still hanging around. This commit ensures a frame gets fully wrapped up before hiding a surface.
2020-06-29 14:21:58 +00:00
{
context_x11->xdamage = 0;
}
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
else
x11: Handle window getting unmapped while frame still pending Since commit 972134abe48a4c9c7b6ad41b0723f30f4e7ae16b we now call glClientWaitSync for the vendor nvidia driver, to know when a frame is ready for the compositor to process. If a surface is hidden while a frame is still being rendered by the GPU, the surface will never produce the damage event the code relies on to trigger the call to glClientWaitSync. This leaves the fence dangling, and the next time the surface is shown, it will start a fresh frame and blow an assertion since the fence from the last frame is still hanging around. This commit ensures a frame gets fully wrapped up before hiding a surface.
2020-06-29 14:21:58 +00:00
{
g_signal_connect_object (G_OBJECT (display),
"xevent",
G_CALLBACK (on_gl_surface_xevent),
context,
G_CONNECT_SWAPPED);
g_signal_connect_object (G_OBJECT (surface),
"notify::state",
G_CALLBACK (on_surface_state_changed),
context,
G_CONNECT_SWAPPED);
}
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
}
#endif
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
context_x11->is_direct = glXIsDirect (dpy, context_x11->glx_context);
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL,
x11: Don't use g_print for debug output The g_print documentation explicitly says not to do this, since g_print is meant to be redirected by applications. Instead use g_message for logging that can be triggered via GTK_DEBUG.
2016-02-29 02:29:16 +00:00
g_message ("Realized GLX context[%p], %s",
context_x11->glx_context,
context_x11->is_direct ? "direct" : "indirect"));
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
return TRUE;
}
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
static void
gdk_x11_gl_context_dispose (GObject *gobject)
{
GdkX11GLContext *context_x11 = GDK_X11_GL_CONTEXT (gobject);
if (context_x11->glx_context != NULL)
{
GdkGLContext *context = GDK_GL_CONTEXT (gobject);
GdkGLContext: Add display property We need to use this in the code path where we make the context non-current during destroy, because at that point the window could be destroyed and gdk_window_get_display() would return NULL.
2014-11-03 12:20:55 +00:00
GdkDisplay *display = gdk_gl_context_get_display (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
Display *dpy = gdk_x11_display_get_xdisplay (display);
if (glXGetCurrentContext () == context_x11->glx_context)
glXMakeContextCurrent (dpy, None, None, NULL);
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL, g_message ("Destroying GLX 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
glXDestroyContext (dpy, context_x11->glx_context);
context_x11->glx_context = NULL;
}
x11: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
#ifdef HAVE_XDAMAGE
context_x11->xdamage = 0;
#endif
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
G_OBJECT_CLASS (gdk_x11_gl_context_parent_class)->dispose (gobject);
}
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)
{
GdkGLContextClass *context_class = GDK_GL_CONTEXT_CLASS (klass);
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
GdkDrawContextClass *draw_context_class = GDK_DRAW_CONTEXT_CLASS (klass);
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
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
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: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
context_class->realize = gdk_x11_gl_context_realize;
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
context_class->get_damage = gdk_x11_gl_context_get_damage;
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
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
draw_context_class->end_frame = gdk_x11_gl_context_end_frame;
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
gobject_class->dispose = gdk_x11_gl_context_dispose;
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_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
}
gboolean
x11: Stop using GdkScreen altogether Derive GdkX11Screen directly from GObject, and remove the last remaining uses of GdkScreen.
2017-11-17 15:37:52 +00:00
gdk_x11_screen_init_gl (GdkX11Screen *screen)
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: Stop using gdk_screen_get_display Never necessary, we can just use the field directly.
2017-11-01 23:41:45 +00:00
GdkDisplay *display = GDK_SCREEN_DISPLAY (screen);
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
GdkX11Display *display_x11 = GDK_X11_DISPLAY (display);
Display *dpy;
int error_base, event_base;
int screen_num;
if (display_x11->have_glx)
return TRUE;
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
if (GDK_DISPLAY_DEBUG_CHECK (display, GL_DISABLE))
Don't initialize GL if it has been disabled We've observed hangs of mutter when it initializes GTK+, which are caused by initializing GL, which in turn makes xwayland call back into mutter. With this change, mutter should just disable GL support in GDK, and things will work.
2014-12-19 17:27:31 +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
dpy = gdk_x11_display_get_xdisplay (display);
x11: Query whether we have GLX support Epoxy 1.4 has new ad hoc API that we can use to check whether GLX is available on the current system. If we didn't use this API, we'd have to manually dlopen libGL (or its equivalent on different OSes) and check if it had GLX symbols; since Epoxy already does all of this internally, we can simply ask it instead. https://bugzilla.gnome.org/show_bug.cgi?id=775279
2017-02-16 00:04:50 +00:00
if (!epoxy_has_glx (dpy))
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
if (!glXQueryExtension (dpy, &error_base, &event_base))
return FALSE;
x11: Stop using GdkScreen altogether Derive GdkX11Screen directly from GObject, and remove the last remaining uses of GdkScreen.
2017-11-17 15:37:52 +00:00
screen_num = screen->screen_num;
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
display_x11->have_glx = TRUE;
display_x11->glx_version = epoxy_glx_version (dpy, screen_num);
display_x11->glx_error_base = error_base;
display_x11->glx_event_base = event_base;
display_x11->has_glx_create_context =
epoxy_has_glx_extension (dpy, screen_num, "GLX_ARB_create_context_profile");
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
display_x11->has_glx_create_es2_context =
epoxy_has_glx_extension (dpy, screen_num, "GLX_EXT_create_context_es2_profile");
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
display_x11->has_glx_swap_interval =
epoxy_has_glx_extension (dpy, screen_num, "GLX_SGI_swap_control");
display_x11->has_glx_texture_from_pixmap =
epoxy_has_glx_extension (dpy, screen_num, "GLX_EXT_texture_from_pixmap");
display_x11->has_glx_video_sync =
epoxy_has_glx_extension (dpy, screen_num, "GLX_SGI_video_sync");
display_x11->has_glx_buffer_age =
epoxy_has_glx_extension (dpy, screen_num, "GLX_EXT_buffer_age");
display_x11->has_glx_sync_control =
epoxy_has_glx_extension (dpy, screen_num, "GLX_OML_sync_control");
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
display_x11->has_glx_multisample =
epoxy_has_glx_extension (dpy, screen_num, "GLX_ARB_multisample");
display_x11->has_glx_visual_rating =
epoxy_has_glx_extension (dpy, screen_num, "GLX_EXT_visual_rating");
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: Defer _NET_WM_FRAME_DRAWN update until frame usable by compositor With the vendor provided Nvidia driver there is a small window of time after drawing to a GL surface before the updates to that surface can be used by the compositor. Drawing is already coordinated with the compositor through the frame synchronization protocol detailed here: https://fishsoup.net/misc/wm-spec-synchronization.html Unfortunately, at the moment, GdkX11Surface tells the compositor the frame is ready immediately after drawing to the surface, not later, when it's consumable by the compositor. This commit defers announcing the frame as ready until it's consumable by the compositor. It does this by listening for the X server to announce damage events associated with the frame drawing. It tries to find the right damage event by waiting until fence placed at buffer swap time signals.
2020-05-27 19:12:35 +00:00
if (g_strcmp0 (glXGetClientString (dpy, GLX_VENDOR), "NVIDIA Corporation") == 0)
{
/* With the mesa based drivers, we can safely assume the compositor can
* access the updated surface texture immediately after glXSwapBuffers is
* run, because the kernel ensures there is an implicit synchronization
* operation upon texture access. This is not true with the Nvidia vendor
* driver. There is a window of time after glXSwapBuffers before other
* processes can see the updated drawing. We need to take special care,
* in that case, to defer telling the compositor our latest frame is
* ready until after the GPU has completed all issued commands related
* to the frame, and that the X server says the frame has been drawn.
*/
display_x11->has_async_glx_swap_buffers = TRUE;
}
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL,
x11: Don't use g_print for debug output The g_print documentation explicitly says not to do this, since g_print is meant to be redirected by applications. Instead use g_message for logging that can be triggered via GTK_DEBUG.
2016-02-29 02:29:16 +00:00
g_message ("GLX version %d.%d found\n"
" - Vendor: %s\n"
" - Checked extensions:\n"
"\t* GLX_ARB_create_context_profile: %s\n"
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
"\t* GLX_EXT_create_context_es2_profile: %s\n"
x11: Don't use g_print for debug output The g_print documentation explicitly says not to do this, since g_print is meant to be redirected by applications. Instead use g_message for logging that can be triggered via GTK_DEBUG.
2016-02-29 02:29:16 +00:00
"\t* GLX_SGI_swap_control: %s\n"
"\t* GLX_EXT_texture_from_pixmap: %s\n"
"\t* GLX_SGI_video_sync: %s\n"
"\t* GLX_EXT_buffer_age: %s\n"
x11: Print all tested glx extensions When initializing a glx context, print all the extensions we look for.
2020-09-10 21:30:28 +00:00
"\t* GLX_OML_sync_control: %s"
"\t* GLX_ARB_multisample: %s"
"\t* GLX_EXT_visual_rating: %s",
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
display_x11->glx_version / 10,
display_x11->glx_version % 10,
glXGetClientString (dpy, GLX_VENDOR),
display_x11->has_glx_create_context ? "yes" : "no",
x11: Allow creating GLES contexts We need to check for the GLX_EXT_create_context_es2_profile extension, which allows us to create a GLES context while using the GLX API.
2016-04-22 17:01:19 +00:00
display_x11->has_glx_create_es2_context ? "yes" : "no",
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
display_x11->has_glx_swap_interval ? "yes" : "no",
display_x11->has_glx_texture_from_pixmap ? "yes" : "no",
display_x11->has_glx_video_sync ? "yes" : "no",
display_x11->has_glx_buffer_age ? "yes" : "no",
x11: Print all tested glx extensions When initializing a glx context, print all the extensions we look for.
2020-09-10 21:30:28 +00:00
display_x11->has_glx_sync_control ? "yes" : "no",
display_x11->has_glx_multisample ? "yes" : "no",
display_x11->has_glx_visual_rating ? "yes" : "no"));
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 TRUE;
}
#define MAX_GLX_ATTRS 30
static gboolean
x11: Remove unused complexity With all Windows having the same visual, there's only ever one visual we need to check.
2016-11-03 04:38:07 +00:00
find_fbconfig (GdkDisplay *display,
GLXFBConfig *fb_config_out,
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
{
static int attrs[MAX_GLX_ATTRS];
Display *dpy = gdk_x11_display_get_xdisplay (display);
GLXFBConfig *configs;
int n_configs, i;
gboolean retval = FALSE;
x11: Replace gdk_display_get_window_visual() ... with functions that don't use GdkVisual. A small step towards getting rid of GdkVisual.
2016-11-03 21:40:36 +00:00
VisualID xvisual_id = XVisualIDFromVisual (gdk_x11_display_get_window_visual (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
i = 0;
attrs[i++] = GLX_DRAWABLE_TYPE;
attrs[i++] = GLX_WINDOW_BIT;
attrs[i++] = GLX_RENDER_TYPE;
attrs[i++] = GLX_RGBA_BIT;
attrs[i++] = GLX_DOUBLEBUFFER;
attrs[i++] = GL_TRUE;
attrs[i++] = GLX_RED_SIZE;
GdkGLContextX11: Ensure we get the fbconfig with the exact same visual We really want a gl context with exactly the same visual, or we will get a badmatch later, which hits us on nvidia as per: https://bugzilla.gnome.org/show_bug.cgi?id=738670
2014-10-28 15:43:38 +00:00
attrs[i++] = 1;
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
attrs[i++] = GLX_GREEN_SIZE;
GdkGLContextX11: Ensure we get the fbconfig with the exact same visual We really want a gl context with exactly the same visual, or we will get a badmatch later, which hits us on nvidia as per: https://bugzilla.gnome.org/show_bug.cgi?id=738670
2014-10-28 15:43:38 +00:00
attrs[i++] = 1;
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
attrs[i++] = GLX_BLUE_SIZE;
GdkGLContextX11: Ensure we get the fbconfig with the exact same visual We really want a gl context with exactly the same visual, or we will get a badmatch later, which hits us on nvidia as per: https://bugzilla.gnome.org/show_bug.cgi?id=738670
2014-10-28 15:43:38 +00:00
attrs[i++] = 1;
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: Remove unused complexity With all Windows having the same visual, there's only ever one visual we need to check.
2016-11-03 04:38:07 +00:00
if (gdk_display_is_rgba (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
{
attrs[i++] = GLX_ALPHA_SIZE;
attrs[i++] = 1;
}
else
{
attrs[i++] = GLX_ALPHA_SIZE;
attrs[i++] = GLX_DONT_CARE;
}
attrs[i++] = None;
g_assert (i < MAX_GLX_ATTRS);
configs = glXChooseFBConfig (dpy, DefaultScreen (dpy), attrs, &n_configs);
if (configs == NULL || n_configs == 0)
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_UNSUPPORTED_FORMAT,
_("No available configurations for the given pixel format"));
return FALSE;
}
for (i = 0; i < n_configs; i++)
{
XVisualInfo *visinfo;
visinfo = glXGetVisualFromFBConfig (dpy, configs[i]);
if (visinfo == NULL)
GdkGLContextX11: Don't free NULL visual info
2014-10-29 10:25:21 +00:00
continue;
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
GdkGLContextX11: Ensure we get the fbconfig with the exact same visual We really want a gl context with exactly the same visual, or we will get a badmatch later, which hits us on nvidia as per: https://bugzilla.gnome.org/show_bug.cgi?id=738670
2014-10-28 15:43:38 +00:00
if (visinfo->visualid != xvisual_id)
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
{
XFree (visinfo);
continue;
}
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
GdkGLContextX11: Ensure we get the fbconfig with the exact same visual We really want a gl context with exactly the same visual, or we will get a badmatch later, which hits us on nvidia as per: https://bugzilla.gnome.org/show_bug.cgi?id=738670
2014-10-28 15:43:38 +00:00
if (fb_config_out != NULL)
*fb_config_out = configs[i];
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: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
XFree (visinfo);
GdkGLContextX11: Ensure we get the fbconfig with the exact same visual We really want a gl context with exactly the same visual, or we will get a badmatch later, which hits us on nvidia as per: https://bugzilla.gnome.org/show_bug.cgi?id=738670
2014-10-28 15:43:38 +00:00
retval = TRUE;
goto out;
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
}
g_set_error (error, GDK_GL_ERROR,
GDK_GL_ERROR_UNSUPPORTED_FORMAT,
_("No available configurations for the given RGBA pixel format"));
out:
XFree (configs);
return retval;
}
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
struct glvisualinfo {
int supports_gl;
int double_buffer;
int stereo;
int alpha_size;
int depth_size;
int stencil_size;
int num_multisample;
int visual_caveat;
};
static gboolean
Drop GdkVisual This type was unused except for serving as a parent for GdkX11Visual. Just move the fields to that type.
2017-11-01 02:44:15 +00:00
visual_compatible (const GdkX11Visual *a, const GdkX11Visual *b)
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
{
return a->type == b->type &&
a->depth == b->depth &&
a->red_mask == b->red_mask &&
a->green_mask == b->green_mask &&
a->blue_mask == b->blue_mask &&
a->colormap_size == b->colormap_size &&
a->bits_per_rgb == b->bits_per_rgb;
}
static gboolean
Drop GdkVisual This type was unused except for serving as a parent for GdkX11Visual. Just move the fields to that type.
2017-11-01 02:44:15 +00:00
visual_is_rgba (const GdkX11Visual *visual)
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
{
return
visual->depth == 32 &&
visual->red_mask == 0xff0000 &&
visual->green_mask == 0x00ff00 &&
visual->blue_mask == 0x0000ff;
}
/* This picks a compatible (as in has the same X visual details) visual
that has "better" characteristics on the GL side */
Drop GdkVisual This type was unused except for serving as a parent for GdkX11Visual. Just move the fields to that type.
2017-11-01 02:44:15 +00:00
static GdkX11Visual *
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
pick_better_visual_for_gl (GdkX11Screen *x11_screen,
struct glvisualinfo *gl_info,
Drop GdkVisual This type was unused except for serving as a parent for GdkX11Visual. Just move the fields to that type.
2017-11-01 02:44:15 +00:00
GdkX11Visual *compatible)
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
{
Drop GdkVisual This type was unused except for serving as a parent for GdkX11Visual. Just move the fields to that type.
2017-11-01 02:44:15 +00:00
GdkX11Visual *visual;
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
int i;
gboolean want_alpha = visual_is_rgba (compatible);
/* First look for "perfect match", i.e:
* supports gl
* double buffer
* alpha iff visual is an rgba visual
* no unnecessary stuff
*/
for (i = 0; i < x11_screen->nvisuals; i++)
{
visual = x11_screen->visuals[i];
if (visual_compatible (visual, compatible) &&
gl_info[i].supports_gl &&
gl_info[i].double_buffer &&
!gl_info[i].stereo &&
(want_alpha ? (gl_info[i].alpha_size > 0) : (gl_info[i].alpha_size == 0)) &&
(gl_info[i].depth_size == 0) &&
(gl_info[i].stencil_size == 0) &&
(gl_info[i].num_multisample == 0) &&
(gl_info[i].visual_caveat == GLX_NONE_EXT))
return visual;
}
if (!want_alpha)
{
/* Next, allow alpha even if we don't want it: */
for (i = 0; i < x11_screen->nvisuals; i++)
{
visual = x11_screen->visuals[i];
if (visual_compatible (visual, compatible) &&
gl_info[i].supports_gl &&
gl_info[i].double_buffer &&
!gl_info[i].stereo &&
(gl_info[i].depth_size == 0) &&
(gl_info[i].stencil_size == 0) &&
(gl_info[i].num_multisample == 0) &&
(gl_info[i].visual_caveat == GLX_NONE_EXT))
return visual;
}
}
/* Next, allow depth and stencil buffers: */
for (i = 0; i < x11_screen->nvisuals; i++)
{
visual = x11_screen->visuals[i];
if (visual_compatible (visual, compatible) &&
gl_info[i].supports_gl &&
gl_info[i].double_buffer &&
!gl_info[i].stereo &&
(gl_info[i].num_multisample == 0) &&
(gl_info[i].visual_caveat == GLX_NONE_EXT))
return visual;
}
/* Next, allow multisample: */
for (i = 0; i < x11_screen->nvisuals; i++)
{
visual = x11_screen->visuals[i];
if (visual_compatible (visual, compatible) &&
gl_info[i].supports_gl &&
gl_info[i].double_buffer &&
!gl_info[i].stereo &&
(gl_info[i].visual_caveat == GLX_NONE_EXT))
return visual;
}
return compatible;
}
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
static gboolean
get_cached_gl_visuals (GdkDisplay *display, int *system, int *rgba)
{
gboolean found;
Atom type_return;
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int format_return;
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
gulong nitems_return;
gulong bytes_after_return;
guchar *data = NULL;
Display *dpy;
dpy = gdk_x11_display_get_xdisplay (display);
found = FALSE;
gdk_x11_display_error_trap_push (display);
if (XGetWindowProperty (dpy, DefaultRootWindow (dpy),
gdk_x11_get_xatom_by_name_for_display (display, "GDK_VISUALS"),
0, 2, False, XA_INTEGER, &type_return,
&format_return, &nitems_return,
&bytes_after_return, &data) == Success)
{
if (type_return == XA_INTEGER &&
format_return == 32 &&
nitems_return == 2 &&
data != NULL)
{
long *visuals = (long *) data;
*system = (int)visuals[0];
*rgba = (int)visuals[1];
found = TRUE;
}
}
gdk_x11_display_error_trap_pop_ignored (display);
if (data)
XFree (data);
return found;
}
static void
save_cached_gl_visuals (GdkDisplay *display, int system, int rgba)
{
long visualdata[2];
Display *dpy;
dpy = gdk_x11_display_get_xdisplay (display);
visualdata[0] = system;
visualdata[1] = rgba;
gdk_x11_display_error_trap_push (display);
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
XChangeProperty (dpy, DefaultRootWindow (dpy),
gdk_x11_get_xatom_by_name_for_display (display, "GDK_VISUALS"),
XA_INTEGER, 32, PropModeReplace,
(unsigned char *)visualdata, 2);
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
gdk_x11_display_error_trap_pop_ignored (display);
}
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
void
x11: Stop using GdkScreen in api This type is going away, so switch to using GdkX11Screen everywhere.
2017-11-17 15:18:20 +00:00
_gdk_x11_screen_update_visuals_for_gl (GdkX11Screen *x11_screen)
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
{
GdkDisplay *display;
GdkX11Display *display_x11;
Display *dpy;
struct glvisualinfo *gl_info;
int i;
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
int system_visual_id, rgba_visual_id;
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
display = x11_screen->display;
display_x11 = GDK_X11_DISPLAY (display);
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
dpy = gdk_x11_display_get_xdisplay (display);
/* We save the default visuals as a property on the root window to avoid
having to initialize GL each time, as it may not be used later. */
if (get_cached_gl_visuals (display, &system_visual_id, &rgba_visual_id))
{
for (i = 0; i < x11_screen->nvisuals; i++)
{
Drop GdkVisual This type was unused except for serving as a parent for GdkX11Visual. Just move the fields to that type.
2017-11-01 02:44:15 +00:00
GdkX11Visual *visual = x11_screen->visuals[i];
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
int visual_id = gdk_x11_visual_get_xvisual (visual)->visualid;
if (visual_id == system_visual_id)
x11_screen->system_visual = visual;
if (visual_id == rgba_visual_id)
x11_screen->rgba_visual = visual;
}
return;
}
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
x11: Stop using GdkScreen in api This type is going away, so switch to using GdkX11Screen everywhere.
2017-11-17 15:18:20 +00:00
if (!gdk_x11_screen_init_gl (x11_screen))
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +00:00
return;
gl_info = g_new0 (struct glvisualinfo, x11_screen->nvisuals);
for (i = 0; i < x11_screen->nvisuals; i++)
{
XVisualInfo *visual_list;
XVisualInfo visual_template;
int nxvisuals;
visual_template.screen = x11_screen->screen_num;
visual_template.visualid = gdk_x11_visual_get_xvisual (x11_screen->visuals[i])->visualid;
visual_list = XGetVisualInfo (x11_screen->xdisplay, VisualIDMask| VisualScreenMask, &visual_template, &nxvisuals);
if (visual_list == NULL)
continue;
glXGetConfig (dpy, &visual_list[0], GLX_USE_GL, &gl_info[i].supports_gl);
glXGetConfig (dpy, &visual_list[0], GLX_DOUBLEBUFFER, &gl_info[i].double_buffer);
glXGetConfig (dpy, &visual_list[0], GLX_STEREO, &gl_info[i].stereo);
glXGetConfig (dpy, &visual_list[0], GLX_ALPHA_SIZE, &gl_info[i].alpha_size);
glXGetConfig (dpy, &visual_list[0], GLX_DEPTH_SIZE, &gl_info[i].depth_size);
glXGetConfig (dpy, &visual_list[0], GLX_STENCIL_SIZE, &gl_info[i].stencil_size);
if (display_x11->has_glx_multisample)
glXGetConfig(dpy, &visual_list[0], GLX_SAMPLE_BUFFERS_ARB, &gl_info[i].num_multisample);
if (display_x11->has_glx_visual_rating)
glXGetConfig(dpy, &visual_list[0], GLX_VISUAL_CAVEAT_EXT, &gl_info[i].visual_caveat);
else
gl_info[i].visual_caveat = GLX_NONE_EXT;
XFree (visual_list);
}
x11_screen->system_visual = pick_better_visual_for_gl (x11_screen, gl_info, x11_screen->system_visual);
if (x11_screen->rgba_visual)
x11_screen->rgba_visual = pick_better_visual_for_gl (x11_screen, gl_info, x11_screen->rgba_visual);
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
GdkX11GLContext: Fix leak
2014-10-29 12:52:04 +00:00
g_free (gl_info);
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
save_cached_gl_visuals (display,
gdk_x11_visual_get_xvisual (x11_screen->system_visual)->visualid,
x11_screen->rgba_visual ? gdk_x11_visual_get_xvisual (x11_screen->rgba_visual)->visualid : 0);
X11: Pick better system and rgba visuals for GL We want to create windows with the default visuals such that we then have the right visual for GLX when we want to create the paint GL context for the window. For instance, (in bug 738670) the default rgba visual we picked for the NVidia driver had an alpha size of 0 which gave us a BadMatch when later trying to initialize a gl context on it with a alpha FBConfig. Instead of just picking what the Xserver likes for the default, and just picking the first rgba visual we now actually call into GLX to pick an appropriate visual.
2014-10-29 11:35:07 +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
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,
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +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
{
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
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
GdkX11GLContext *context;
GLXFBConfig config;
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);
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
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
if (!gdk_x11_screen_init_gl (GDK_SURFACE_SCREEN (surface)))
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
{
g_set_error_literal (error, GDK_GL_ERROR,
GDK_GL_ERROR_NOT_AVAILABLE,
_("No GL implementation is available"));
return NULL;
}
x11: Remove unused complexity With all Windows having the same visual, there's only ever one visual we need to check.
2016-11-03 04:38:07 +00:00
if (!find_fbconfig (display, &config, 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;
GL: Follow naming conventions All the GDK type defines are GDK_TYPE_..., so follow this pattern for the GLContext subclasses as well.
2014-10-22 03:39:05 +00:00
context = g_object_new (GDK_TYPE_X11_GL_CONTEXT,
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
"surface", surface,
GdkGLContext: Track shared context This allows us to read it back, but primarily it ensures the shared context wrapper stays alive as long as the context.
2014-10-30 11:04:23 +00:00
"shared-context", share,
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
NULL);
context->glx_config = config;
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)
{
GdkX11GLContext *context_x11;
Display *dpy = gdk_x11_display_get_xdisplay (display);
gboolean do_frame_sync = FALSE;
glcontext: Make begin/end_draw() paired This way, we can query the GL context's state via gdk_gl_context_is_drawing(). Use this function to make GL contexts as attached and grant them access to the front/backbuffer for rendering. All of this is still unused because GL drawing is still disabled.
2016-11-23 04:18:43 +00:00
GLXWindow drawable;
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
if (context == NULL)
{
glXMakeContextCurrent (dpy, None, None, NULL);
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
return 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
}
context_x11 = GDK_X11_GL_CONTEXT (context);
x11/gl: Do not try to call MakeCurrent with a NULL context This should not happen, but better safe than sorry. https://bugzilla.gnome.org/show_bug.cgi?id=746746
2015-03-25 15:18:44 +00:00
if (context_x11->glx_context == NULL)
{
g_critical ("No GLX context associated to the GdkGLContext; you must "
"call gdk_gl_context_realize() first.");
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
drawcontext: Add gdk_draw_context_in_frame() API This makes the previous gdk_draw_context_is_drawing() function public under a new name. I decided against the old name because we use the term "frame" for a drawing operation, so I wanted to have this boolean flag reuse the term.
2018-04-23 16:24:29 +00:00
if (context_x11->is_attached || gdk_draw_context_is_in_frame (GDK_DRAW_CONTEXT (context)))
glcontext: Make begin/end_draw() paired This way, we can query the GL context's state via gdk_gl_context_is_drawing(). Use this function to make GL contexts as attached and grant them access to the front/backbuffer for rendering. All of this is still unused because GL drawing is still disabled.
2016-11-23 04:18:43 +00:00
drawable = context_x11->attached_drawable;
else
drawable = context_x11->unattached_drawable;
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL,
glcontext: Make begin/end_draw() paired This way, we can query the GL context's state via gdk_gl_context_is_drawing(). Use this function to make GL contexts as attached and grant them access to the front/backbuffer for rendering. All of this is still unused because GL drawing is still disabled.
2016-11-23 04:18:43 +00:00
g_message ("Making GLX context %p current to drawable %lu",
context, (unsigned long) drawable));
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
glcontext: Make begin/end_draw() paired This way, we can query the GL context's state via gdk_gl_context_is_drawing(). Use this function to make GL contexts as attached and grant them access to the front/backbuffer for rendering. All of this is still unused because GL drawing is still disabled.
2016-11-23 04:18:43 +00:00
if (!glXMakeContextCurrent (dpy, drawable, drawable,
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
context_x11->glx_context))
{
Make gdk logging per-display As far as possible, use per-display debug flags. This will minimize the debug spew that we get from the inspector if it is running on a separate display.
2018-01-12 00:48:27 +00:00
GDK_DISPLAY_NOTE (display, OPENGL,
x11: Don't use g_print for debug output The g_print documentation explicitly says not to do this, since g_print is meant to be redirected by applications. Instead use g_message for logging that can be triggered via GTK_DEBUG.
2016-02-29 02:29:16 +00:00
g_message ("Making GLX context current failed"));
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
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
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
if (context_x11->is_attached && GDK_X11_DISPLAY (display)->has_glx_swap_interval)
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: move some code This moves the code related to the frame sync code into the is_attached check, which means we don't have to ever run this when making non-window-paint contexts current. This is a minior speed thing, but the main advantage is that it makes making a non-paint context current threadsafe.
2014-10-30 15:04:28 +00:00
/* If the WM 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. */
API: screen: Remove gdk_screen_is_composited() Switch code to use gdk_display_is_composited() instead. The new code also doesn't use a vfunc to query the property but rather requires the backend to call set_composited()/set_rgba() to change the value.
2016-10-29 02:37:20 +00:00
do_frame_sync = ! gdk_display_is_composited (display);
gdk_x11_display_make_gl_context_current: move some code This moves the code related to the frame sync code into the is_attached check, which means we don't have to ever run this when making non-window-paint contexts current. This is a minior speed thing, but the main advantage is that it makes making a non-paint context current threadsafe.
2014-10-30 15:04:28 +00:00
GdkGLContextX11: Only set swap interval when it changed
2014-11-05 11:02:18 +00:00
if (do_frame_sync != context_x11->do_frame_sync)
{
context_x11->do_frame_sync = do_frame_sync;
gdk_x11_display_make_gl_context_current: move some code This moves the code related to the frame sync code into the is_attached check, which means we don't have to ever run this when making non-window-paint contexts current. This is a minior speed thing, but the main advantage is that it makes making a non-paint context current threadsafe.
2014-10-30 15:04:28 +00:00
GdkGLContextX11: Only set swap interval when it changed
2014-11-05 11:02:18 +00:00
if (do_frame_sync)
glXSwapIntervalSGI (1);
else
glXSwapIntervalSGI (0);
}
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: 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
return 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
}
/**
* gdk_x11_display_get_glx_version:
gdk/x11: Add annotations to improve GIR API
2020-07-31 17:11:23 +00:00
* @display: (type GdkX11Display): a #GdkDisplay
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
* @major: (out): return location for the GLX major version
* @minor: (out): return location for the GLX minor version
*
* Retrieves the version of the GLX implementation.
*
* Returns: %TRUE if GLX is available
*/
gboolean
gdk_x11_display_get_glx_version (GdkDisplay *display,
Replace "gint" with "int"
2020-07-24 13:54:49 +00:00
int *major,
int *minor)
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
{
g_return_val_if_fail (GDK_IS_DISPLAY (display), FALSE);
if (!GDK_IS_X11_DISPLAY (display))
return FALSE;
x11: Stop using gdk_display_get_default_screen There's no point in using this api here, we can directly get the screen member from the GdkX11Display struct.
2017-11-01 22:06:24 +00:00
if (!gdk_x11_screen_init_gl (GDK_X11_DISPLAY (display)->screen))
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 FALSE;
if (major != NULL)
*major = GDK_X11_DISPLAY (display)->glx_version / 10;
if (minor != NULL)
*minor = GDK_X11_DISPLAY (display)->glx_version % 10;
return TRUE;
}
Reference in New Issue Copy Permalink