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

1249 lines
36 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.c: GL context abstraction
*
* 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/>.
*/
/**
* SECTION:gdkglcontext
* @Title: GdkGLContext
gdk: Cosmetic rewording of draw context docs Avoid draw context <> drawing context confusion, as far as possible.
2017-12-26 19:10:54 +00:00
* @Short_description: OpenGL draw 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
*
* #GdkGLContext is an object representing the platform-specific
gdk: Cosmetic rewording of draw context docs Avoid draw context <> drawing context confusion, as far as possible.
2017-12-26 19:10:54 +00:00
* OpenGL draw 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
*
GdkWindow -> GdkSurface initial type rename This renames the GdkWindow class and related classes (impl, backend subclasses) to surface. Additionally it renames related types: GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType, GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge This is an automatic conversion using the below commands: git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass git sed -f g GdkWindow GdkSurface git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2" git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE" git sed -f g "broadway_window" "broadway_surface" git sed -f g "BroadwayWindow" "BroadwaySurface" git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE" git sed -f g "wayland_window" "wayland_surface" git sed -f g "WaylandWindow" "WaylandSurface" git sed -f g "X11_WINDOW" "X11_SURFACE" git sed -f g "x11_window" "x11_surface" git sed -f g "X11Window" "X11Surface" git sed -f g "WIN32_WINDOW" "WIN32_SURFACE" git sed -f g "win32_window" "win32_surface" git sed -f g "Win32Window" "Win32Surface" git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE" git sed -f g "quartz_window" "quartz_surface" git sed -f g "QuartzWindow" "QuartzSurface" git checkout NEWS* po-properties
2018-03-20 10:40:08 +00:00
* #GdkGLContexts are created for a #GdkSurface using
* gdk_surface_create_gl_context(), and the context will match the
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
* the characteristics of the 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
*
Nitpicky documentation changes
2014-10-12 03:35:52 +00:00
* A #GdkGLContext is not tied to any particular normal framebuffer.
GdkWindow -> GdkSurface initial type rename This renames the GdkWindow class and related classes (impl, backend subclasses) to surface. Additionally it renames related types: GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType, GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge This is an automatic conversion using the below commands: git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass git sed -f g GdkWindow GdkSurface git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2" git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE" git sed -f g "broadway_window" "broadway_surface" git sed -f g "BroadwayWindow" "BroadwaySurface" git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE" git sed -f g "wayland_window" "wayland_surface" git sed -f g "WaylandWindow" "WaylandSurface" git sed -f g "X11_WINDOW" "X11_SURFACE" git sed -f g "x11_window" "x11_surface" git sed -f g "X11Window" "X11Surface" git sed -f g "WIN32_WINDOW" "WIN32_SURFACE" git sed -f g "win32_window" "win32_surface" git sed -f g "Win32Window" "Win32Surface" git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE" git sed -f g "quartz_window" "quartz_surface" git sed -f g "QuartzWindow" "QuartzSurface" git checkout NEWS* po-properties
2018-03-20 10:40:08 +00:00
* For instance, it cannot draw to the #GdkSurface back buffer. The GDK
Nitpicky documentation changes
2014-10-12 03:35:52 +00:00
* repaint system is in full control of the painting to that. Instead,
* you can create render buffers or textures and use gdk_cairo_draw_from_gl()
* in the draw function of your widget to draw them. Then GDK will handle
* the integration of your rendering with that of other widgets.
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
*
Trivial formatting fixes
2014-10-12 03:17:34 +00:00
* Support for #GdkGLContext is platform-specific, context creation
* can fail, returning %NULL 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
*
* A #GdkGLContext has to be made "current" in order to start using
* it, otherwise any OpenGL call will be ignored.
*
* ## Creating a new OpenGL context ##
*
* In order to create a new #GdkGLContext instance you need a
GdkWindow -> GdkSurface initial type rename This renames the GdkWindow class and related classes (impl, backend subclasses) to surface. Additionally it renames related types: GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType, GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge This is an automatic conversion using the below commands: git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass git sed -f g GdkWindow GdkSurface git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2" git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE" git sed -f g "broadway_window" "broadway_surface" git sed -f g "BroadwayWindow" "BroadwaySurface" git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE" git sed -f g "wayland_window" "wayland_surface" git sed -f g "WaylandWindow" "WaylandSurface" git sed -f g "X11_WINDOW" "X11_SURFACE" git sed -f g "x11_window" "x11_surface" git sed -f g "X11Window" "X11Surface" git sed -f g "WIN32_WINDOW" "WIN32_SURFACE" git sed -f g "win32_window" "win32_surface" git sed -f g "Win32Window" "Win32Surface" git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE" git sed -f g "quartz_window" "quartz_surface" git sed -f g "QuartzWindow" "QuartzSurface" git checkout NEWS* po-properties
2018-03-20 10:40:08 +00:00
* #GdkSurface, which you typically get during the realize call
Trivial formatting fixes
2014-10-12 03:17:34 +00:00
* of a widget.
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
*
docs: We do not support non-core GL profiles No need to mention that some API only works on core GL profiles in the GdkGLContext docs. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:09:25 +00:00
* A #GdkGLContext is not realized until either gdk_gl_context_make_current(),
* or until it is realized using gdk_gl_context_realize(). It is possible to
* specify details of the GL context like the OpenGL version to be used, or
* whether the GL context should have extra state validation enabled after
GdkWindow -> GdkSurface initial type rename This renames the GdkWindow class and related classes (impl, backend subclasses) to surface. Additionally it renames related types: GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType, GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge This is an automatic conversion using the below commands: git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass git sed -f g GdkWindow GdkSurface git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2" git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE" git sed -f g "broadway_window" "broadway_surface" git sed -f g "BroadwayWindow" "BroadwaySurface" git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE" git sed -f g "wayland_window" "wayland_surface" git sed -f g "WaylandWindow" "WaylandSurface" git sed -f g "X11_WINDOW" "X11_SURFACE" git sed -f g "x11_window" "x11_surface" git sed -f g "X11Window" "X11Surface" git sed -f g "WIN32_WINDOW" "WIN32_SURFACE" git sed -f g "win32_window" "win32_surface" git sed -f g "Win32Window" "Win32Surface" git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE" git sed -f g "quartz_window" "quartz_surface" git sed -f g "QuartzWindow" "QuartzSurface" git checkout NEWS* po-properties
2018-03-20 10:40:08 +00:00
* calling gdk_surface_create_gl_context() by calling gdk_gl_context_realize().
docs: We do not support non-core GL profiles No need to mention that some API only works on core GL profiles in the GdkGLContext docs. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:09:25 +00:00
* If the realization fails you have the option to change the settings of the
* #GdkGLContext and try again.
*
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
* ## Using a GdkGLContext ##
*
* You will need to make the #GdkGLContext the current context
* before issuing OpenGL calls; the system sends OpenGL commands to
* whichever context is current. It is possible to have multiple
* contexts, so you always need to ensure that the one which you
* want to draw with is the current one before issuing commands:
*
* |[<!-- language="C" -->
* gdk_gl_context_make_current (context);
* ]|
*
* You can now perform your drawing using OpenGL commands.
*
* You can check which #GdkGLContext is the current one by using
* gdk_gl_context_get_current(); you can also unset any #GdkGLContext
* that is currently set by calling gdk_gl_context_clear_current().
*/
Document more structs
2017-12-26 19:39:24 +00:00
/**
* GdkGLContext:
*
* The GdkGLContext struct contains only private fields and
* should not be accessed directly.
*/
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 "config.h"
#include "gdkglcontextprivate.h"
#include "gdkdisplayprivate.h"
#include "gdkinternals.h"
#include "gdkintl.h"
Move GDK GL flags accessors to the private vtable This allows us to use the GDK_PRIVATE_CALL macro inside gtk. https://bugzilla.gnome.org/show_bug.cgi?id=739781
2014-11-07 14:27:56 +00:00
#include "gdk-private.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
OpenGL/ES: Fix 'R' and 'B' bits inverted on Windows We need to use GL_BGRA instead of GL_RGBA when doing glReadPixels() on EGL on Windows (ANGLE) so that the red and blue bits won't be displayed inverted. Also fix the logic where we determine whether to bit blit or redraw everything.
2018-07-31 10:18:59 +00:00
#ifdef GDK_WINDOWING_WIN32
# include "gdk/win32/gdkwin32.h"
#endif
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
#include <epoxy/gl.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
typedef struct {
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
GdkGLContext *shared_context;
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
int major;
int minor;
gl: Add gdk_gl_context_get_version() Store the OpenGL version when we first do the extensions check; this allows client code to check the available GL version without requiring a call to gdk_gl_context_make_current() and epoxy_gl_version().
2015-02-12 14:28:22 +00:00
int gl_version;
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
guint realized : 1;
guint use_texture_rectangle : 1;
Add gdk_gl_context_has_framebuffer_blit() This checks if the context supports GL_EXT_framebuffer_blit
2014-11-06 11:13:08 +00:00
guint has_gl_framebuffer_blit : 1;
GdkX11GLContext: Use bitblit for swap if no buffer age support If buffer age is undefined and the updated area is not the whole window then we use bit-blits instead of swap-buffers to end the frame. This allows us to not repaint the entire window unnecessarily if buffer_age is not supported, like e.g. with DRI2.
2014-11-06 11:21:28 +00:00
guint has_frame_terminator : 1;
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
guint has_khr_debug : 1;
gdkglcontext: Only emit opengl debug calls if GDK_DEBUG=gl-debug This avoids a potential performance cost in the non-debug case.
2019-04-24 13:23:32 +00:00
guint use_khr_debug : 1;
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
guint has_unpack_subimage : 1;
GdkGLContext: Add a GL debug message callback If G_ENABLE_CONSISTENCY_CHECKS is defined (i.e. if our buildtype is 'debug'), add a opengl debug callback that prints all debug messages with a severity higher than SEVERITY_NOTIFICATION as a warning to the console.
2018-03-25 13:28:40 +00:00
guint has_debug_output : 1;
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
guint extensions_checked : 1;
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
guint debug_enabled : 1;
guint forward_compatible : 1;
gdk: Allow querying if a GL context is in legacy mode We want to have the ability to fall back to legacy GL contexts when creating them. In order to do so, we need to store the legacy bit on the GdkGLContext, as well as being able to query it. Setting the legacy bit from outside GDK is not possible; we cannot create GL contexts in 3.2 core profile *and* compatibility modes at the same time, and if we allowed users to select the legacy mode themselves, it would break the creation of the GdkWindow's paint GL context. What we do allow is falling back to legacy GL context if the platform does not support 3.2 core profiles — for instance, on older GPUs or inside virtualized environments. We are also going to use the legacy bit internally, to choose which GL API we can use when drawing GL content. https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-06 17:54:58 +00:00
guint is_legacy : 1;
gdk/gl: Allow autodetection for GL/GLES If the GdkGLContext was not explicitly instructed to use or not GLES, we can detect whether the underlying API is going to be desktop GL or GLES. https://bugzilla.gnome.org/show_bug.cgi?id=773180
2016-10-19 12:43:17 +00:00
int use_es;
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
gdkglcontext: Limit gl debug label length There's a maximum length we have to adhere to, otherwise GL throws a GL_INVALID_VALUE error.
2019-04-27 07:49:41 +00:00
int max_debug_label_length;
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
GdkGLContextPaintData *paint_data;
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
} GdkGLContextPrivate;
enum {
PROP_0,
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
PROP_SHARED_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
LAST_PROP
};
static GParamSpec *obj_pspecs[LAST_PROP] = { NULL, };
G_DEFINE_QUARK (gdk-gl-error-quark, gdk_gl_error)
gdk: Turn GdkGLContext into a GdkDrawContext
2016-11-28 16:36:37 +00:00
G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE (GdkGLContext, gdk_gl_context, GDK_TYPE_DRAW_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
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 GPrivate thread_current_context = G_PRIVATE_INIT (g_object_unref);
glcontext: Store the buffer age regions in the GL context That way, we can store the right region there: The actual painted area instead of the exposed area (which is way too small). Also, the GL context is the only user of this data, so storing it there seems way smarter.
2018-04-08 22:58:31 +00:00
static void
gdk_gl_context_clear_old_updated_area (GdkGLContext *context)
{
int i;
for (i = 0; i < 2; i++)
{
g_clear_pointer (&context->old_updated_area[i], cairo_region_destroy);
}
}
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_gl_context_dispose (GObject *gobject)
{
GdkGLContext *context = GDK_GL_CONTEXT (gobject);
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (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
GdkGLContext *current;
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: Store the buffer age regions in the GL context That way, we can store the right region there: The actual painted area instead of the exposed area (which is way too small). Also, the GL context is the only user of this data, so storing it there seems way smarter.
2018-04-08 22:58:31 +00:00
gdk_gl_context_clear_old_updated_area (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
current = g_private_get (&thread_current_context);
if (current == context)
g_private_replace (&thread_current_context, NULL);
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
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
g_clear_object (&priv->shared_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
G_OBJECT_CLASS (gdk_gl_context_parent_class)->dispose (gobject);
}
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
static void
gdk_gl_context_finalize (GObject *gobject)
{
GdkGLContext *context = GDK_GL_CONTEXT (gobject);
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
g_clear_pointer (&priv->paint_data, g_free);
GdkGLContext: chain finalize handler https://bugzilla.gnome.org/show_bug.cgi?id=773979
2016-11-05 13:21:22 +00:00
G_OBJECT_CLASS (gdk_gl_context_parent_class)->finalize (gobject);
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
}
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
static void
gdk_gl_context_set_property (GObject *gobject,
guint prop_id,
const GValue *value,
GParamSpec *pspec)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private ((GdkGLContext *) gobject);
switch (prop_id)
{
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
case PROP_SHARED_CONTEXT:
{
GdkGLContext *context = g_value_get_object (value);
if (context != NULL)
priv->shared_context = g_object_ref (context);
}
break;
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
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (gobject, prop_id, pspec);
}
}
static void
gdk_gl_context_get_property (GObject *gobject,
guint prop_id,
GValue *value,
GParamSpec *pspec)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private ((GdkGLContext *) gobject);
switch (prop_id)
{
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
case PROP_SHARED_CONTEXT:
g_value_set_object (value, priv->shared_context);
break;
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
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (gobject, prop_id, pspec);
}
}
gl: Drop GdkGLContextClass.upload_texture() It's unnecessary to allow per-backend overrides.
2015-02-09 19:09:31 +00:00
void
gdkgl: Use vfunc For Uploading Textures As the alignments, strides and image formats may be different across platforms, make the texture upload a vfunc to allow backends to override the GL commands for uploading textures for the software implementation for gdk_gl_texture_from_surface(), if necessary. Suggested by Alex to avoid copying non-trivial portions of code which would then add maintainenace burden. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 08:06:25 +00:00
gdk_gl_context_upload_texture (GdkGLContext *context,
gdkgl: Change prototype of function The function does not upload a cairo surface, it uploads pixel data. So don't take a cairo surface as an argument, take pixel data.
2016-11-01 03:47:52 +00:00
const guchar *data,
gdkgl: Use vfunc For Uploading Textures As the alignments, strides and image formats may be different across platforms, make the texture upload a vfunc to allow backends to override the GL commands for uploading textures for the software implementation for gdk_gl_texture_from_surface(), if necessary. Suggested by Alex to avoid copying non-trivial portions of code which would then add maintainenace burden. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 08:06:25 +00:00
int width,
int height,
gdkgl: Change prototype of function The function does not upload a cairo surface, it uploads pixel data. So don't take a cairo surface as an argument, take pixel data.
2016-11-01 03:47:52 +00:00
int stride,
gdkgl: Use vfunc For Uploading Textures As the alignments, strides and image formats may be different across platforms, make the texture upload a vfunc to allow backends to override the GL commands for uploading textures for the software implementation for gdk_gl_texture_from_surface(), if necessary. Suggested by Alex to avoid copying non-trivial portions of code which would then add maintainenace burden. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 08:06:25 +00:00
guint texture_target)
{
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gdkgl: Use vfunc For Uploading Textures As the alignments, strides and image formats may be different across platforms, make the texture upload a vfunc to allow backends to override the GL commands for uploading textures for the software implementation for gdk_gl_texture_from_surface(), if necessary. Suggested by Alex to avoid copying non-trivial portions of code which would then add maintainenace burden. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 08:06:25 +00:00
g_return_if_fail (GDK_IS_GL_CONTEXT (context));
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
/* GL_UNPACK_ROW_LENGTH is available on desktop GL, OpenGL ES >= 3.0, or if
* the GL_EXT_unpack_subimage extension for OpenGL ES 2.0 is available
*/
gl: Add fallback for missing subimage unpacking For GLES 2.0 platforms with the subimage unpacking extension we need to upload one row of the image surface at a time.
2016-04-25 09:31:51 +00:00
if (!priv->use_es ||
(priv->use_es && (priv->gl_version >= 30 || priv->has_unpack_subimage)))
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
{
glPixelStorei (GL_UNPACK_ALIGNMENT, 4);
gdkgl: Change prototype of function The function does not upload a cairo surface, it uploads pixel data. So don't take a cairo surface as an argument, take pixel data.
2016-11-01 03:47:52 +00:00
glPixelStorei (GL_UNPACK_ROW_LENGTH, stride / 4);
gl: Use the appropriate format on GLES When uploading a Cairo image surface to a GL texture we cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV on OpenGL ES, as they do not exist in the core spec.
2016-04-23 09:21:13 +00:00
gl: Add fallback for missing subimage unpacking For GLES 2.0 platforms with the subimage unpacking extension we need to upload one row of the image surface at a time.
2016-04-25 09:31:51 +00:00
if (priv->use_es)
gl: Use the appropriate format on GLES When uploading a Cairo image surface to a GL texture we cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV on OpenGL ES, as they do not exist in the core spec.
2016-04-23 09:21:13 +00:00
glTexImage2D (texture_target, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE,
gdkgl: Change prototype of function The function does not upload a cairo surface, it uploads pixel data. So don't take a cairo surface as an argument, take pixel data.
2016-11-01 03:47:52 +00:00
data);
gl: Use the appropriate format on GLES When uploading a Cairo image surface to a GL texture we cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV on OpenGL ES, as they do not exist in the core spec.
2016-04-23 09:21:13 +00:00
else
glTexImage2D (texture_target, 0, GL_RGBA, width, height, 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV,
gdkgl: Change prototype of function The function does not upload a cairo surface, it uploads pixel data. So don't take a cairo surface as an argument, take pixel data.
2016-11-01 03:47:52 +00:00
data);
gl: Use the appropriate format on GLES When uploading a Cairo image surface to a GL texture we cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV on OpenGL ES, as they do not exist in the core spec.
2016-04-23 09:21:13 +00:00
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
glPixelStorei (GL_UNPACK_ROW_LENGTH, 0);
}
else
gl: Add fallback for missing subimage unpacking For GLES 2.0 platforms with the subimage unpacking extension we need to upload one row of the image surface at a time.
2016-04-25 09:31:51 +00:00
{
int i;
if (priv->use_es)
{
glTexImage2D (texture_target, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
for (i = 0; i < height; i++)
gdkgl: Change prototype of function The function does not upload a cairo surface, it uploads pixel data. So don't take a cairo surface as an argument, take pixel data.
2016-11-01 03:47:52 +00:00
glTexSubImage2D (texture_target, 0, 0, i, width, 1, GL_RGBA, GL_UNSIGNED_BYTE, data + (i * stride));
gl: Add fallback for missing subimage unpacking For GLES 2.0 platforms with the subimage unpacking extension we need to upload one row of the image surface at a time.
2016-04-25 09:31:51 +00:00
}
else
{
glTexImage2D (texture_target, 0, GL_RGBA, width, height, 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, NULL);
for (i = 0; i < height; i++)
gdkgl: Change prototype of function The function does not upload a cairo surface, it uploads pixel data. So don't take a cairo surface as an argument, take pixel data.
2016-11-01 03:47:52 +00:00
glTexSubImage2D (texture_target, 0, 0, i, width, 1, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, data + (i * stride));
gl: Add fallback for missing subimage unpacking For GLES 2.0 platforms with the subimage unpacking extension we need to upload one row of the image surface at a time.
2016-04-25 09:31:51 +00:00
}
}
gdkgl: Use vfunc For Uploading Textures As the alignments, strides and image formats may be different across platforms, make the texture upload a vfunc to allow backends to override the GL commands for uploading textures for the software implementation for gdk_gl_texture_from_surface(), if necessary. Suggested by Alex to avoid copying non-trivial portions of code which would then add maintainenace burden. https://bugzilla.gnome.org/show_bug.cgi?id=740795
2014-12-17 08:06:25 +00:00
}
gl: Add a realize() fallback Calling gdk_gl_context_realize() should always result in a valid result, so we need to provide a default implementation, to avoid a call to a NULL function pointer.
2016-05-23 07:31:47 +00:00
static gboolean
gdk_gl_context_real_realize (GdkGLContext *self,
GError **error)
{
g_set_error_literal (error, GDK_GL_ERROR, GDK_GL_ERROR_NOT_AVAILABLE,
"The current backend does not support OpenGL");
return FALSE;
}
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_gl_context_real_get_damage (GdkGLContext *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_draw_context_get_surface (GDK_DRAW_CONTEXT (context));
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 cairo_region_create_rectangle (&(GdkRectangle) {
0, 0,
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_surface_get_width (surface),
gdk_surface_get_height (surface)
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
});
}
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
static void
gdk_gl_context_real_begin_frame (GdkDrawContext *draw_context,
cairo_region_t *region)
{
GdkGLContext *context = GDK_GL_CONTEXT (draw_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: 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 *shared;
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
cairo_region_t *damage;
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
int ww, wh;
shared = gdk_gl_context_get_shared_context (context);
if (shared)
{
gdk: Move begin/end_frame() functions As they require a draw context and the draw context is already bound to the surface, it makes much more sense and reduces abiguity by moving these APIs to the draw context. As a side effect, we simplify GdkSurface APIs to a point where GdkSurface now does not concern itself with drawing anymore at all, apart from being the object that creates draw contexts.
2018-04-23 15:28:55 +00:00
GDK_DRAW_CONTEXT_GET_CLASS (GDK_DRAW_CONTEXT (shared))->begin_frame (GDK_DRAW_CONTEXT (shared), region);
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
return;
}
gdk: Remove gdk_gl_context_get_damage() Remove it only form public API, because we still use the vfunc to figure out the damage area in begin_frame().
2018-04-20 15:04:36 +00:00
damage = GDK_GL_CONTEXT_GET_CLASS (context)->get_damage (context);
glcontext: Store the updated area in the right place We need to store the region *before* adding our own damage area, because we want to only store the changes of this frame, not the whole history. So do it in the same place Vulkan does it. Fixes #1900
2019-05-18 14:54:27 +00:00
if (context->old_updated_area[1])
cairo_region_destroy (context->old_updated_area[1]);
context->old_updated_area[1] = context->old_updated_area[0];
context->old_updated_area[0] = cairo_region_copy (region);
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
cairo_region_union (region, damage);
cairo_region_destroy (damage);
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_draw_context_get_surface (draw_context);
ww = gdk_surface_get_width (surface) * gdk_surface_get_scale_factor (surface);
wh = gdk_surface_get_height (surface) * gdk_surface_get_scale_factor (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
gdk_gl_context_make_current (context);
/* Initial setup */
glClearColor (0.0f, 0.0f, 0.0f, 0.0f);
glDisable (GL_DEPTH_TEST);
glDisable (GL_BLEND);
glBlendFunc (GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
glViewport (0, 0, ww, wh);
}
static void
gdk_gl_context_real_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: Make gdk_window_begin_draw_frame() take a draw context ... instead of a gl context. This requires some refactoring in the way we mark the shared context as drawing: We now call begin_frame/end_frame() on it and ignore the call on the main context. Unfortunately we need to do this check in all vfuncs, which sucks. But I haven't found a better way.
2016-12-01 00:38:20 +00:00
{
GdkGLContext *context = GDK_GL_CONTEXT (draw_context);
GdkGLContext *shared;
shared = gdk_gl_context_get_shared_context (context);
if (shared)
{
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_GET_CLASS (GDK_DRAW_CONTEXT (shared))->end_frame (GDK_DRAW_CONTEXT (shared), 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
return;
}
glcontext: Store the buffer age regions in the GL context That way, we can store the right region there: The actual painted area instead of the exposed area (which is way too small). Also, the GL context is the only user of this data, so storing it there seems way smarter.
2018-04-08 22:58:31 +00:00
}
static void
gdk_gl_context_surface_resized (GdkDrawContext *draw_context)
{
GdkGLContext *context = GDK_GL_CONTEXT (draw_context);
gdk_gl_context_clear_old_updated_area (context);
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: 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_gl_context_class_init (GdkGLContextClass *klass)
{
GObjectClass *gobject_class = G_OBJECT_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);
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: Add a realize() fallback Calling gdk_gl_context_realize() should always result in a valid result, so we need to provide a default implementation, to avoid a call to a NULL function pointer.
2016-05-23 07:31:47 +00:00
klass->realize = gdk_gl_context_real_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
klass->get_damage = gdk_gl_context_real_get_damage;
gl: Add a realize() fallback Calling gdk_gl_context_realize() should always result in a valid result, so we need to provide a default implementation, to avoid a call to a NULL function pointer.
2016-05-23 07:31:47 +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->begin_frame = gdk_gl_context_real_begin_frame;
draw_context_class->end_frame = gdk_gl_context_real_end_frame;
glcontext: Store the buffer age regions in the GL context That way, we can store the right region there: The actual painted area instead of the exposed area (which is way too small). Also, the GL context is the only user of this data, so storing it there seems way smarter.
2018-04-08 22:58:31 +00:00
draw_context_class->surface_resized = gdk_gl_context_surface_resized;
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: 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
/**
* GdkGLContext:shared-context:
*
doc: Replace uses of #NULL with %NULL
2017-11-22 19:19:27 +00:00
* The #GdkGLContext that this context is sharing data with, or %NULL
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
*/
obj_pspecs[PROP_SHARED_CONTEXT] =
g_param_spec_object ("shared-context",
P_("Shared context"),
GdkGLContext little fix to property names and descriptions. https://bugzilla.gnome.org/show_bug.cgi?id=752502
2015-07-16 16:22:07 +00:00
P_("The GL context this context shares data with"),
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
GDK_TYPE_GL_CONTEXT,
G_PARAM_READWRITE |
G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
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
gobject_class->set_property = gdk_gl_context_set_property;
gobject_class->get_property = gdk_gl_context_get_property;
gobject_class->dispose = gdk_gl_context_dispose;
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
gobject_class->finalize = gdk_gl_context_finalize;
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_object_class_install_properties (gobject_class, LAST_PROP, obj_pspecs);
}
static void
gdk_gl_context_init (GdkGLContext *self)
{
gdk/gl: Allow autodetection for GL/GLES If the GdkGLContext was not explicitly instructed to use or not GLES, we can detect whether the underlying API is going to be desktop GL or GLES. https://bugzilla.gnome.org/show_bug.cgi?id=773180
2016-10-19 12:43:17 +00:00
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (self);
priv->use_es = -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
}
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
GdkGLContextPaintData *
gdk_gl_context_get_paint_data (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
if (priv->paint_data == NULL)
gl: Store the legacy bit in the GL program data We need to know if we're using a legacy GL context in various places. https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-06 18:55:07 +00:00
{
priv->paint_data = g_new0 (GdkGLContextPaintData, 1);
priv->paint_data->is_legacy = priv->is_legacy;
gl: Relay use-es from context to paint data This way we can select the appropriate API or the appropriate shaders. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:21:36 +00:00
priv->paint_data->use_es = priv->use_es;
gl: Store the legacy bit in the GL program data We need to know if we're using a legacy GL context in various places. https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-06 18:55:07 +00:00
}
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
return priv->paint_data;
}
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
gboolean
gdk_gl_context_use_texture_rectangle (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
return priv->use_texture_rectangle;
}
Add gdk_gl_context_has_framebuffer_blit() This checks if the context supports GL_EXT_framebuffer_blit
2014-11-06 11:13:08 +00:00
gboolean
gdk_gl_context_has_framebuffer_blit (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
return priv->has_gl_framebuffer_blit;
}
GdkX11GLContext: Use bitblit for swap if no buffer age support If buffer age is undefined and the updated area is not the whole window then we use bit-blits instead of swap-buffers to end the frame. This allows us to not repaint the entire window unnecessarily if buffer_age is not supported, like e.g. with DRI2.
2014-11-06 11:21:28 +00:00
gboolean
gdk_gl_context_has_frame_terminator (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
return priv->has_frame_terminator;
}
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
void
gdk_gl_context_push_debug_group (GdkGLContext *context,
const char *message)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gdkglcontext: Only emit opengl debug calls if GDK_DEBUG=gl-debug This avoids a potential performance cost in the non-debug case.
2019-04-24 13:23:32 +00:00
if (priv->use_khr_debug)
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
glPushDebugGroupKHR (GL_DEBUG_SOURCE_APPLICATION, 0, -1, message);
}
void
gdk_gl_context_push_debug_group_printf (GdkGLContext *context,
const char *format,
...)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
char *message;
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
va_list args;
gdkglcontext: Only emit opengl debug calls if GDK_DEBUG=gl-debug This avoids a potential performance cost in the non-debug case.
2019-04-24 13:23:32 +00:00
if (priv->use_khr_debug)
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
{
gdkglcontext: Limit gl debug label length There's a maximum length we have to adhere to, otherwise GL throws a GL_INVALID_VALUE error.
2019-04-27 07:49:41 +00:00
int msg_len;
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
va_start (args, format);
message = g_strdup_vprintf (format, args);
va_end (args);
gdkglcontext: Limit gl debug label length There's a maximum length we have to adhere to, otherwise GL throws a GL_INVALID_VALUE error.
2019-04-27 07:49:41 +00:00
msg_len = MIN (priv->max_debug_label_length, strlen (message) - 1);
glPushDebugGroupKHR (GL_DEBUG_SOURCE_APPLICATION, 0, msg_len, message);
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
g_free (message);
}
}
void
gdk_gl_context_pop_debug_group (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gdkglcontext: Only emit opengl debug calls if GDK_DEBUG=gl-debug This avoids a potential performance cost in the non-debug case.
2019-04-24 13:23:32 +00:00
if (priv->use_khr_debug)
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
glPopDebugGroupKHR ();
}
void
gdk_gl_context_label_object (GdkGLContext *context,
guint identifier,
guint name,
const char *label)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gdkglcontext: Only emit opengl debug calls if GDK_DEBUG=gl-debug This avoids a potential performance cost in the non-debug case.
2019-04-24 13:23:32 +00:00
if (priv->use_khr_debug)
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
glObjectLabel (identifier, name, -1, label);
}
void
gdk_gl_context_label_object_printf (GdkGLContext *context,
guint identifier,
guint name,
const char *format,
...)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
char *message;
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
va_list args;
gdkglcontext: Only emit opengl debug calls if GDK_DEBUG=gl-debug This avoids a potential performance cost in the non-debug case.
2019-04-24 13:23:32 +00:00
if (priv->use_khr_debug)
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
{
gdkglcontext: Limit gl debug label length There's a maximum length we have to adhere to, otherwise GL throws a GL_INVALID_VALUE error.
2019-04-27 07:49:41 +00:00
int msg_len;
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
va_start (args, format);
message = g_strdup_vprintf (format, args);
va_end (args);
gdkglcontext: Limit gl debug label length There's a maximum length we have to adhere to, otherwise GL throws a GL_INVALID_VALUE error.
2019-04-27 07:49:41 +00:00
msg_len = MIN (priv->max_debug_label_length, strlen (message) - 1);
glObjectLabel (identifier, name, msg_len, message);
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
g_free (message);
}
}
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
gboolean
gdk_gl_context_has_unpack_subimage (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
return priv->has_unpack_subimage;
}
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
/**
* gdk_gl_context_set_debug_enabled:
* @context: a #GdkGLContext
* @enabled: whether to enable debugging in the context
*
* Sets whether the #GdkGLContext should perform extra validations and
* run time checking. This is useful during development, but has
* additional overhead.
*
docs: We do not support non-core GL profiles No need to mention that some API only works on core GL profiles in the GdkGLContext docs. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:09:25 +00:00
* The #GdkGLContext must not be realized or made current prior to
* calling this function.
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
*/
void
gdk_gl_context_set_debug_enabled (GdkGLContext *context,
gboolean enabled)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
g_return_if_fail (GDK_IS_GL_CONTEXT (context));
g_return_if_fail (!priv->realized);
enabled = !!enabled;
priv->debug_enabled = enabled;
}
gl: Move getters for context options to the public API They can be useful for third party code as well. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 14:37:26 +00:00
/**
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
* gdk_gl_context_get_debug_enabled:
* @context: a #GdkGLContext
*
* Retrieves the value set using gdk_gl_context_set_debug_enabled().
*
* Returns: %TRUE if debugging is enabled
*/
gboolean
gdk_gl_context_get_debug_enabled (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gl: Move getters for context options to the public API They can be useful for third party code as well. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 14:37:26 +00:00
g_return_val_if_fail (GDK_IS_GL_CONTEXT (context), FALSE);
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
return priv->debug_enabled;
}
/**
* gdk_gl_context_set_forward_compatible:
* @context: a #GdkGLContext
* @compatible: whether the context should be forward compatible
*
* Sets whether the #GdkGLContext should be forward compatible.
*
* Forward compatibile contexts must not support OpenGL functionality that
* has been marked as deprecated in the requested version; non-forward
* compatible contexts, on the other hand, must support both deprecated and
* non deprecated functionality.
*
docs: We do not support non-core GL profiles No need to mention that some API only works on core GL profiles in the GdkGLContext docs. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:09:25 +00:00
* The #GdkGLContext must not be realized or made current prior to calling
* this function.
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
*/
void
gdk_gl_context_set_forward_compatible (GdkGLContext *context,
gboolean compatible)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gl: Clean up pre-requisite checks for GdkGLContext setters We don't support non-core profiles. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:08:43 +00:00
g_return_if_fail (GDK_IS_GL_CONTEXT (context));
g_return_if_fail (!priv->realized);
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
compatible = !!compatible;
priv->forward_compatible = compatible;
}
gl: Move getters for context options to the public API They can be useful for third party code as well. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 14:37:26 +00:00
/**
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
* gdk_gl_context_get_forward_compatible:
* @context: a #GdkGLContext
*
* Retrieves the value set using gdk_gl_context_set_forward_compatible().
*
* Returns: %TRUE if the context should be forward compatible
*/
gboolean
gdk_gl_context_get_forward_compatible (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gl: Move getters for context options to the public API They can be useful for third party code as well. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 14:37:26 +00:00
g_return_val_if_fail (GDK_IS_GL_CONTEXT (context), FALSE);
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
return priv->forward_compatible;
}
/**
* gdk_gl_context_set_required_version:
* @context: a #GdkGLContext
* @major: the major version to request
* @minor: the minor version to request
*
* Sets the major and minor version of OpenGL to request.
*
* Setting @major and @minor to zero will use the default values.
*
docs: We do not support non-core GL profiles No need to mention that some API only works on core GL profiles in the GdkGLContext docs. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:09:25 +00:00
* The #GdkGLContext must not be realized or made current prior to calling
* this function.
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
*/
void
gdk_gl_context_set_required_version (GdkGLContext *context,
int major,
int minor)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
Fix compiler warnings in the release build We have a bunch of debug-only variables that get set and never used outside of debug code paths, and the compiler is not happy about it.
2020-01-29 11:00:48 +00:00
gboolean force_gles = FALSE;
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
int version, min_ver;
Fix compiler warnings in the release build We have a bunch of debug-only variables that get set and never used outside of debug code paths, and the compiler is not happy about it.
2020-01-29 11:00:48 +00:00
#ifdef G_ENABLE_DEBUG
GdkDisplay *display;
#endif
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
g_return_if_fail (GDK_IS_GL_CONTEXT (context));
g_return_if_fail (!priv->realized);
gl: Fix the required version setter We don't allow a version tuple to be lower than (3, 2), but we should allow versions above that. https://bugzilla.gnome.org/show_bug.cgi?id=744212
2015-02-10 10:16:53 +00:00
/* this will take care of the default */
if (major == 0 && minor == 0)
{
priv->major = 0;
priv->minor = 0;
return;
}
gl: Warn the user if they request a GL context version less than 3.2 If the user requests a version less than 3.2 the version is forced to 3.2. Previous checking code have an inconsistent behavior depending on which minor version number was specified. This is avoided now by temporarily converting the major/minor pair into a single integer. https://bugzilla.gnome.org/show_bug.cgi?id=744288
2015-02-11 04:35:01 +00:00
version = (major * 100) + minor;
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
Fix compiler warnings in the release build We have a bunch of debug-only variables that get set and never used outside of debug code paths, and the compiler is not happy about it.
2020-01-29 11:00:48 +00:00
#ifdef G_ENABLE_DEBUG
display = gdk_draw_context_get_display (GDK_DRAW_CONTEXT (context));
force_gles = GDK_DISPLAY_DEBUG_CHECK (display, GL_GLES);
#endif
/* Enforce a minimum context version number of 3.2 for desktop GL,
* and 2.0 for GLES
*/
if (priv->use_es > 0 || force_gles)
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
min_ver = 200;
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
else
min_ver = 302;
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
if (version < min_ver)
gl: Warn the user if they request a GL context version less than 3.2 If the user requests a version less than 3.2 the version is forced to 3.2. Previous checking code have an inconsistent behavior depending on which minor version number was specified. This is avoided now by temporarily converting the major/minor pair into a single integer. https://bugzilla.gnome.org/show_bug.cgi?id=744288
2015-02-11 04:35:01 +00:00
{
g_warning ("gdk_gl_context_set_required_version - GL context versions less than 3.2 are not supported.");
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
version = min_ver;
gl: Warn the user if they request a GL context version less than 3.2 If the user requests a version less than 3.2 the version is forced to 3.2. Previous checking code have an inconsistent behavior depending on which minor version number was specified. This is avoided now by temporarily converting the major/minor pair into a single integer. https://bugzilla.gnome.org/show_bug.cgi?id=744288
2015-02-11 04:35:01 +00:00
}
priv->major = version / 100;
priv->minor = version % 100;
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
}
gl: Move getters for context options to the public API They can be useful for third party code as well. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 14:37:26 +00:00
/**
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
* gdk_gl_context_get_required_version:
* @context: a #GdkGLContext
* @major: (out) (nullable): return location for the major version to request
* @minor: (out) (nullable): return location for the minor version to request
*
* Retrieves the major and minor version requested by calling
* gdk_gl_context_set_required_version().
*/
void
gdk_gl_context_get_required_version (GdkGLContext *context,
int *major,
int *minor)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
Fix compiler warnings in the release build We have a bunch of debug-only variables that get set and never used outside of debug code paths, and the compiler is not happy about it.
2020-01-29 11:00:48 +00:00
gboolean force_gles = FALSE;
#ifdef G_ENABLE_DEBUG
GdkDisplay *display;
#endif
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
int default_major, default_minor;
gl: Clean up the required version accessors We can simplify the code, since we only have core GL profiles in GDK. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:10:22 +00:00
int maj, min;
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
gl: Clean up the required version accessors We can simplify the code, since we only have core GL profiles in GDK. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:10:22 +00:00
g_return_if_fail (GDK_IS_GL_CONTEXT (context));
Fix compiler warnings in the release build We have a bunch of debug-only variables that get set and never used outside of debug code paths, and the compiler is not happy about it.
2020-01-29 11:00:48 +00:00
#ifdef G_ENABLE_DEBUG
display = gdk_draw_context_get_display (GDK_DRAW_CONTEXT (context));
force_gles = GDK_DISPLAY_DEBUG_CHECK (display, GL_GLES);
#endif
/* Default fallback values for uninitialised contexts; we
* enforce a context version number of 3.2 for desktop GL,
* and 2.0 for GLES
*/
if (priv->use_es > 0 || force_gles)
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
{
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
default_major = 2;
default_minor = 0;
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
}
else
{
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
default_major = 3;
default_minor = 2;
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
}
gl: Clean up the required version accessors We can simplify the code, since we only have core GL profiles in GDK. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:10:22 +00:00
if (priv->major > 0)
maj = priv->major;
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
else
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
maj = default_major;
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
gl: Clean up the required version accessors We can simplify the code, since we only have core GL profiles in GDK. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:10:22 +00:00
if (priv->minor > 0)
min = priv->minor;
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
else
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
min = default_minor;
gl: Clean up the required version accessors We can simplify the code, since we only have core GL profiles in GDK. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:10:22 +00:00
if (major != NULL)
*major = maj;
if (minor != NULL)
*minor = min;
gl: Add context options Users of the GdkGLContext API should be allowed to set properties on the shim GdkGLContext instance prior to realization, so that the backend-specific implementation can use the value of those properties when creating the windowing system specific resources. The main three options are: • a major/minor version tuple, to request a specific GL version • a debug bit, to request a "debug context", which provides additional validation and run time checking • a forward compatibility bit, to request a context that does not have deprecated functionality See also: - https://www.opengl.org/registry/specs/ARB/glx_create_context.txt https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 09:34:16 +00:00
}
gdk: Allow querying if a GL context is in legacy mode We want to have the ability to fall back to legacy GL contexts when creating them. In order to do so, we need to store the legacy bit on the GdkGLContext, as well as being able to query it. Setting the legacy bit from outside GDK is not possible; we cannot create GL contexts in 3.2 core profile *and* compatibility modes at the same time, and if we allowed users to select the legacy mode themselves, it would break the creation of the GdkWindow's paint GL context. What we do allow is falling back to legacy GL context if the platform does not support 3.2 core profiles — for instance, on older GPUs or inside virtualized environments. We are also going to use the legacy bit internally, to choose which GL API we can use when drawing GL content. https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-06 17:54:58 +00:00
/**
* gdk_gl_context_is_legacy:
* @context: a #GdkGLContext
*
* Whether the #GdkGLContext is in legacy mode or not.
*
docs: Improve description of gdk_gl_context_is_legacy() Explain why this function is available, and why you may need it. https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-07 07:50:23 +00:00
* The #GdkGLContext must be realized before calling this function.
*
* When realizing a GL context, GDK will try to use the OpenGL 3.2 core
* profile; this profile removes all the OpenGL API that was deprecated
* prior to the 3.2 version of the specification. If the realization is
* successful, this function will return %FALSE.
*
* If the underlying OpenGL implementation does not support core profiles,
* GDK will fall back to a pre-3.2 compatibility profile, and this function
* will return %TRUE.
*
* You can use the value returned by this function to decide which kind
* of OpenGL API to use, or whether to do extension discovery, or what
* kind of shader programs to load.
gdk: Allow querying if a GL context is in legacy mode We want to have the ability to fall back to legacy GL contexts when creating them. In order to do so, we need to store the legacy bit on the GdkGLContext, as well as being able to query it. Setting the legacy bit from outside GDK is not possible; we cannot create GL contexts in 3.2 core profile *and* compatibility modes at the same time, and if we allowed users to select the legacy mode themselves, it would break the creation of the GdkWindow's paint GL context. What we do allow is falling back to legacy GL context if the platform does not support 3.2 core profiles — for instance, on older GPUs or inside virtualized environments. We are also going to use the legacy bit internally, to choose which GL API we can use when drawing GL content. https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-06 17:54:58 +00:00
*
* Returns: %TRUE if the GL context is in legacy mode
*/
gboolean
gdk_gl_context_is_legacy (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
g_return_val_if_fail (GDK_IS_GL_CONTEXT (context), FALSE);
g_return_val_if_fail (priv->realized, FALSE);
return priv->is_legacy;
}
void
gdk_gl_context_set_is_legacy (GdkGLContext *context,
gboolean is_legacy)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
priv->is_legacy = !!is_legacy;
}
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
/**
* gdk_gl_context_set_use_es:
* @context: a #GdkGLContext:
gdk/gl: Allow autodetection for GL/GLES If the GdkGLContext was not explicitly instructed to use or not GLES, we can detect whether the underlying API is going to be desktop GL or GLES. https://bugzilla.gnome.org/show_bug.cgi?id=773180
2016-10-19 12:43:17 +00:00
* @use_es: whether the context should use OpenGL ES instead of OpenGL,
* or -1 to allow auto-detection
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
*
Minor typos in the Documentation (a/an)
2019-08-25 12:52:24 +00:00
* Requests that GDK create an OpenGL ES context instead of an OpenGL one,
docs: Clarify the platform-dependency of GdkGLContext:use-es Not all platforms allow creating an OpenGL ES context.
2016-04-23 09:33:08 +00:00
* if the platform and windowing system allows it.
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
*
* The @context must not have been realized.
*
gdk/gl: Allow autodetection for GL/GLES If the GdkGLContext was not explicitly instructed to use or not GLES, we can detect whether the underlying API is going to be desktop GL or GLES. https://bugzilla.gnome.org/show_bug.cgi?id=773180
2016-10-19 12:43:17 +00:00
* By default, GDK will attempt to automatically detect whether the
* underlying GL implementation is OpenGL or OpenGL ES once the @context
* is realized.
*
docs: Clarify the platform-dependency of GdkGLContext:use-es Not all platforms allow creating an OpenGL ES context.
2016-04-23 09:33:08 +00:00
* You should check the return value of gdk_gl_context_get_use_es() after
* calling gdk_gl_context_realize() to decide whether to use the OpenGL or
* OpenGL ES API, extensions, or shaders.
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
*/
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
void
gdk_gl_context_set_use_es (GdkGLContext *context,
gdk/gl: Allow autodetection for GL/GLES If the GdkGLContext was not explicitly instructed to use or not GLES, we can detect whether the underlying API is going to be desktop GL or GLES. https://bugzilla.gnome.org/show_bug.cgi?id=773180
2016-10-19 12:43:17 +00:00
int use_es)
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
g_return_if_fail (GDK_IS_GL_CONTEXT (context));
g_return_if_fail (!priv->realized);
gdk/gl: Allow autodetection for GL/GLES If the GdkGLContext was not explicitly instructed to use or not GLES, we can detect whether the underlying API is going to be desktop GL or GLES. https://bugzilla.gnome.org/show_bug.cgi?id=773180
2016-10-19 12:43:17 +00:00
if (priv->use_es != use_es)
priv->use_es = use_es;
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
}
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
/**
* gdk_gl_context_get_use_es:
* @context: a #GdkGLContext
*
* Checks whether the @context is using an OpenGL or OpenGL ES profile.
*
* Returns: %TRUE if the #GdkGLContext is using an OpenGL ES profile
*/
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
gboolean
gdk_gl_context_get_use_es (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
g_return_val_if_fail (GDK_IS_GL_CONTEXT (context), FALSE);
gdk/gl: Allow autodetection for GL/GLES If the GdkGLContext was not explicitly instructed to use or not GLES, we can detect whether the underlying API is going to be desktop GL or GLES. https://bugzilla.gnome.org/show_bug.cgi?id=773180
2016-10-19 12:43:17 +00:00
if (!priv->realized)
return FALSE;
return priv->use_es > 0;
gl: Add 'use-es' flag On some platforms we can ask the GL context machinery to create a GLES context, instead of a GL one. In order to ask for a GLES context at GdkGLContext realization time, we use a bit field like we do for forward compatible, or debug contexts. The 'use-es' bit also changes the way we select a default version, because OpenGL and OpenGLES versions differ. https://bugzilla.gnome.org/show_bug.cgi?id=743746
2016-04-18 09:10:30 +00:00
}
GdkGLContext: Add a GL debug message callback If G_ENABLE_CONSISTENCY_CHECKS is defined (i.e. if our buildtype is 'debug'), add a opengl debug callback that prints all debug messages with a severity higher than SEVERITY_NOTIFICATION as a warning to the console.
2018-03-25 13:28:40 +00:00
#ifdef G_ENABLE_CONSISTENCY_CHECKS
static void
gl_debug_message_callback (GLenum source,
GLenum type,
GLuint id,
GLenum severity,
GLsizei length,
const GLchar *message,
const void *user_data)
{
const char *message_source;
const char *message_type;
const char *message_severity;
if (severity == GL_DEBUG_SEVERITY_NOTIFICATION)
return;
switch (source)
{
case GL_DEBUG_SOURCE_API:
message_source = "API";
break;
case GL_DEBUG_SOURCE_WINDOW_SYSTEM:
message_source = "Window System";
break;
case GL_DEBUG_SOURCE_SHADER_COMPILER:
message_source = "Shader Compiler";
break;
case GL_DEBUG_SOURCE_THIRD_PARTY:
message_source = "Third Party";
break;
case GL_DEBUG_SOURCE_APPLICATION:
message_source = "Application";
break;
case GL_DEBUG_SOURCE_OTHER:
default:
message_source = "Other";
}
switch (type)
{
case GL_DEBUG_TYPE_ERROR:
message_type = "Error";
break;
case GL_DEBUG_TYPE_DEPRECATED_BEHAVIOR:
message_type = "Deprecated Behavior";
break;
case GL_DEBUG_TYPE_UNDEFINED_BEHAVIOR:
message_type = "Undefined Behavior";
break;
case GL_DEBUG_TYPE_PORTABILITY:
message_type = "Portability";
break;
case GL_DEBUG_TYPE_PERFORMANCE:
message_type = "Performance";
break;
case GL_DEBUG_TYPE_MARKER:
message_type = "Marker";
break;
case GL_DEBUG_TYPE_PUSH_GROUP:
message_type = "Push Group";
break;
case GL_DEBUG_TYPE_POP_GROUP:
message_type = "Pop Group";
break;
case GL_DEBUG_TYPE_OTHER:
default:
message_type = "Other";
}
switch (severity)
{
case GL_DEBUG_SEVERITY_HIGH:
message_severity = "High";
break;
case GL_DEBUG_SEVERITY_MEDIUM:
message_severity = "Medium";
break;
case GL_DEBUG_SEVERITY_LOW:
message_severity = "Low";
break;
case GL_DEBUG_SEVERITY_NOTIFICATION:
message_severity = "Notification";
break;
default:
message_severity = "Unknown";
}
g_warning ("OPENGL:\n Source: %s\n Type: %s\n Severity: %s\n Message: %s",
message_source, message_type, message_severity, message);
}
#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
/**
* gdk_gl_context_realize:
* @context: a #GdkGLContext
* @error: return location for a #GError
*
* Realizes the given #GdkGLContext.
*
* It is safe to call this function on a realized #GdkGLContext.
*
* Returns: %TRUE if the context is realized
*/
gboolean
gdk_gl_context_realize (GdkGLContext *context,
GError **error)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
g_return_val_if_fail (GDK_IS_GL_CONTEXT (context), FALSE);
if (priv->realized)
gl: Clean up the required version accessors We can simplify the code, since we only have core GL profiles in GDK. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-09 16:10:22 +00:00
return TRUE;
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
priv->realized = GDK_GL_CONTEXT_GET_CLASS (context)->realize (context, error);
return priv->realized;
}
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
static void
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
gdk_gl_context_check_extensions (GdkGLContext *context)
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
gboolean has_npot, has_texture_rectangle;
Fix compiler warnings in the release build We have a bunch of debug-only variables that get set and never used outside of debug code paths, and the compiler is not happy about it.
2020-01-29 11:00:48 +00:00
gboolean gl_debug = FALSE;
#ifdef G_ENABLE_DEBUG
GdkDisplay *display;
#endif
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +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 (!priv->realized)
return;
if (priv->extensions_checked)
return;
gl: Add gdk_gl_context_get_version() Store the OpenGL version when we first do the extensions check; this allows client code to check the available GL version without requiring a call to gdk_gl_context_make_current() and epoxy_gl_version().
2015-02-12 14:28:22 +00:00
priv->gl_version = epoxy_gl_version ();
gdk/gl: Allow autodetection for GL/GLES If the GdkGLContext was not explicitly instructed to use or not GLES, we can detect whether the underlying API is going to be desktop GL or GLES. https://bugzilla.gnome.org/show_bug.cgi?id=773180
2016-10-19 12:43:17 +00:00
if (priv->use_es < 0)
priv->use_es = !epoxy_is_desktop_gl ();
GdkGLContext: check for GL_KHR_debug for GL debug output This is available in GLES.
2019-12-17 08:06:15 +00:00
priv->has_debug_output = epoxy_has_gl_extension ("GL_ARB_debug_output") ||
epoxy_has_gl_extension ("GL_KHR_debug");
GdkGLContext: Add a GL debug message callback If G_ENABLE_CONSISTENCY_CHECKS is defined (i.e. if our buildtype is 'debug'), add a opengl debug callback that prints all debug messages with a severity higher than SEVERITY_NOTIFICATION as a warning to the console.
2018-03-25 13:28:40 +00:00
#ifdef G_ENABLE_CONSISTENCY_CHECKS
if (priv->has_debug_output)
{
gdk_gl_context_make_current (context);
glEnable (GL_DEBUG_OUTPUT);
glEnable (GL_DEBUG_OUTPUT_SYNCHRONOUS);
glDebugMessageCallback (gl_debug_message_callback, NULL);
}
#endif
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
if (priv->use_es)
{
has_npot = priv->gl_version >= 20;
has_texture_rectangle = FALSE;
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
/* This should check for GL_NV_framebuffer_blit as well - see extension at:
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
*
* https://www.khronos.org/registry/gles/extensions/NV/NV_framebuffer_blit.txt
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
*
* for ANGLE, we can enable bit blitting if we have the
* GL_ANGLE_framebuffer_blit extension
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
*/
Add a EGL renderer (via ANGLE) for Windows This is for adding a EGL-based renderer which is done via the ANGLE project, which translate EGL calls to Direct3D 9/11. This is done as a possible solution to issue #105, especially for cases where the needed full GL extensions to map OpenGL to Direct3D is unavailable or unreliable, or when the OpenGL implementation from the graphics drivers are problematic. To enable this, do the following: -Build ANGLE and ensure the ANGLE libEGL.dll and libGLESv2.dll are available. A sufficiently-recent ANGLE is needed for things to work correctly--note that the copy of ANGLE that is included in qtbase-5.10.1 is sufficient. ANGLE is licensed under a BSD 3-clause license. -Build libepoxy on Windows with EGL support enabled. -Currently, prior to running GTK+ programs, the GDK_DEBUG envvar needs to be set with gl-gles as at least one of the flags. Known issues: -Only OpenGL ES 3 is supported, ANGLE's ES 2 does not support the needed extensions, notably GL_OES_vertex_array_object, but its ES 3 support is sufficient. -There is no autodetection or fallback mechanism to enable using EGL/Angle automatically yet. There are no plans to do this in this commit.
2018-07-31 10:11:26 +00:00
priv->has_gl_framebuffer_blit = epoxy_has_gl_extension ("GL_ANGLE_framebuffer_blit");
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
/* No OES version */
priv->has_frame_terminator = FALSE;
priv->has_unpack_subimage = epoxy_has_gl_extension ("GL_EXT_unpack_subimage");
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
priv->has_khr_debug = epoxy_has_gl_extension ("GL_KHR_debug");
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
}
else
{
Fixed OpenGL extension detection for extensions promoted to OpenGL core. For a given OpenGL context, macOS in particular does not support enumeration / detection of OpenGL features that have been promoted to core OpenGL functionality. It is possible other drivers are the same. This change assumes support for GL_ARB_texture_non_power_of_two with OpenGL 2.0+, GL_ARB_texture_rectangle with OpenGL 3.1+ and GL_EXT_framebuffer_blit with OpenGL 3.0+. I failed to find definitive information on whether GL_GREMEDY_frame_terminator has been promoted to OpenGL core, or whether GL_ANGLE_framebuffer_blit or GL_EXT_unpack_subimage have been promoted to core in OpenGL ES. This change results in a significant GtkGLArea performance boost on macOS. Closes #2428
2020-02-12 19:52:24 +00:00
has_npot = priv->gl_version >= 20 || epoxy_has_gl_extension ("GL_ARB_texture_non_power_of_two");
has_texture_rectangle = priv->gl_version >= 31 || epoxy_has_gl_extension ("GL_ARB_texture_rectangle");
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
Fixed OpenGL extension detection for extensions promoted to OpenGL core. For a given OpenGL context, macOS in particular does not support enumeration / detection of OpenGL features that have been promoted to core OpenGL functionality. It is possible other drivers are the same. This change assumes support for GL_ARB_texture_non_power_of_two with OpenGL 2.0+, GL_ARB_texture_rectangle with OpenGL 3.1+ and GL_EXT_framebuffer_blit with OpenGL 3.0+. I failed to find definitive information on whether GL_GREMEDY_frame_terminator has been promoted to OpenGL core, or whether GL_ANGLE_framebuffer_blit or GL_EXT_unpack_subimage have been promoted to core in OpenGL ES. This change results in a significant GtkGLArea performance boost on macOS. Closes #2428
2020-02-12 19:52:24 +00:00
priv->has_gl_framebuffer_blit = priv->gl_version >= 30 || epoxy_has_gl_extension ("GL_EXT_framebuffer_blit");
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
priv->has_frame_terminator = epoxy_has_gl_extension ("GL_GREMEDY_frame_terminator");
priv->has_unpack_subimage = TRUE;
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
priv->has_khr_debug = epoxy_has_gl_extension ("GL_KHR_debug");
gl: Set legacy bit depending on OpenGL version GDK defaults to asking for an OpenGL 3.2 Core Profile, but if we get a legacy profile from the underlying windowing system, the OpenGL version will be fixed to 3.0. If that happens, we need to set the legacy bit on the GdkGLContext, since that bit will be used to determine the version and type of GLSL shaders that will be used by application and toolkit code alike.
2016-10-21 20:21:39 +00:00
/* We asked for a core profile, but we didn't get one, so we're in legacy mode */
if (priv->gl_version < 32)
priv->is_legacy = TRUE;
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
}
Add gdk_gl_context_has_framebuffer_blit() This checks if the context supports GL_EXT_framebuffer_blit
2014-11-06 11:13:08 +00:00
Fix compiler warnings in the release build We have a bunch of debug-only variables that get set and never used outside of debug code paths, and the compiler is not happy about it.
2020-01-29 11:00:48 +00:00
#ifdef G_ENABLE_DEBUG
display = gdk_draw_context_get_display (GDK_DRAW_CONTEXT (context));
gl_debug = GDK_DISPLAY_DEBUG_CHECK (display, GL_DEBUG);
#endif
if (priv->has_khr_debug && gl_debug)
gdkglcontext: Limit gl debug label length There's a maximum length we have to adhere to, otherwise GL throws a GL_INVALID_VALUE error.
2019-04-27 07:49:41 +00:00
{
priv->use_khr_debug = TRUE;
glGetIntegerv (GL_MAX_LABEL_LENGTH, &priv->max_debug_label_length);
}
gdk: Silence some compiler warnings These cause unused variable warnings in release builds.
2020-02-04 21:54:19 +00:00
if (!priv->use_es && GDK_DISPLAY_DEBUG_CHECK (gdk_draw_context_get_display (GDK_DRAW_CONTEXT (context)), GL_TEXTURE_RECT))
Add support for GDK_GL=texture-rectangles This allows us to test our support for GL_ARB_texture_rectangle
2014-11-06 10:29:51 +00:00
priv->use_texture_rectangle = TRUE;
else if (has_npot)
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
priv->use_texture_rectangle = FALSE;
else if (has_texture_rectangle)
priv->use_texture_rectangle = TRUE;
else
Export API to set GL flags This will be used in the inspector.
2014-11-07 04:29:16 +00:00
g_warning ("GL implementation doesn't support any form of non-power-of-two textures");
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +00:00
gdk: Silence some compiler warnings These cause unused variable warnings in release builds.
2020-02-04 21:54:19 +00:00
GDK_DISPLAY_NOTE (gdk_draw_context_get_display (GDK_DRAW_CONTEXT (context)), OPENGL,
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
g_message ("%s version: %d.%d (%s)\n"
gl: Set legacy bit depending on OpenGL version GDK defaults to asking for an OpenGL 3.2 Core Profile, but if we get a legacy profile from the underlying windowing system, the OpenGL version will be fixed to 3.0. If that happens, we need to set the legacy bit on the GdkGLContext, since that bit will be used to determine the version and type of GLSL shaders that will be used by application and toolkit code alike.
2016-10-21 20:21:39 +00:00
"* GLSL version: %s\n"
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
"* Extensions checked:\n"
gdk: 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-28 20:39:05 +00:00
" - GL_ARB_texture_non_power_of_two: %s\n"
" - GL_ARB_texture_rectangle: %s\n"
" - GL_EXT_framebuffer_blit: %s\n"
" - GL_GREMEDY_frame_terminator: %s\n"
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
" - GL_KHR_debug: %s\n"
gl: Add more OpenGL ES checks Check for the appropriate extensions depending on which type of API we're using.
2016-04-22 16:27:04 +00:00
"* Using texture rectangle: %s",
priv->use_es ? "OpenGL ES" : "OpenGL",
gdk: 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-28 20:39:05 +00:00
priv->gl_version / 10, priv->gl_version % 10,
gl: Set legacy bit depending on OpenGL version GDK defaults to asking for an OpenGL 3.2 Core Profile, but if we get a legacy profile from the underlying windowing system, the OpenGL version will be fixed to 3.0. If that happens, we need to set the legacy bit on the GdkGLContext, since that bit will be used to determine the version and type of GLSL shaders that will be used by application and toolkit code alike.
2016-10-21 20:21:39 +00:00
priv->is_legacy ? "legacy" : "core",
glGetString (GL_SHADING_LANGUAGE_VERSION),
gdk: 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-28 20:39:05 +00:00
has_npot ? "yes" : "no",
has_texture_rectangle ? "yes" : "no",
priv->has_gl_framebuffer_blit ? "yes" : "no",
priv->has_frame_terminator ? "yes" : "no",
GdkGLContext: Add internal functions for KHR_DEBUG calls This includes pushing and poping debug group messages and labeling objects.
2019-04-24 11:25:46 +00:00
priv->has_khr_debug ? "yes" : "no",
gdk: 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-28 20:39:05 +00:00
priv->use_texture_rectangle ? "yes" : "no"));
gl: Add more debugging notes https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-02-05 16:23:04 +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
priv->extensions_checked = TRUE;
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +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
/**
* gdk_gl_context_make_current:
* @context: a #GdkGLContext
*
* Makes the @context the current one.
*/
gl: Make gdk_gl_context_make_current() return void Its not really reasonable to handle failures to make_current, it basically only happens if you pass invalid arguments to it, and thats not something we trap on similar things on the X drawing side. If GL is not supported that should be handled by the context creation failing, and anything going wrong after that is essentially a critical (or an async X error).
2014-10-09 15:24:21 +00:00
void
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_gl_context_make_current (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (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
GdkGLContext *current;
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 gdk_gl_context_make_current() return void Its not really reasonable to handle failures to make_current, it basically only happens if you pass invalid arguments to it, and thats not something we trap on similar things on the X drawing side. If GL is not supported that should be handled by the context creation failing, and anything going wrong after that is essentially a critical (or an async X error).
2014-10-09 15:24:21 +00:00
g_return_if_fail (GDK_IS_GL_CONTEXT (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
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
current = g_private_get (&thread_current_context);
if (current == context)
return;
gdkglcontext: Track whether to use GL_TEXTURE_2D or GL_TEXTURE_RECTANGL_ARB
2014-10-27 20:12:40 +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
/* we need to realize the GdkGLContext if it wasn't explicitly realized */
if (!priv->realized)
{
GError *error = NULL;
gdk_gl_context_realize (context, &error);
if (error != NULL)
{
g_critical ("Could not realize the GL context: %s", error->message);
g_error_free (error);
return;
}
}
gdk: Turn GdkGLContext into a GdkDrawContext
2016-11-28 16:36:37 +00:00
if (gdk_display_make_gl_context_current (gdk_draw_context_get_display (GDK_DRAW_CONTEXT (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
{
g_private_replace (&thread_current_context, g_object_ref (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
gdk_gl_context_check_extensions (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
}
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: 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
/**
* gdk_gl_context_get_display:
* @context: a #GdkGLContext
*
* Retrieves the #GdkDisplay the @context is created for
*
Add some missing (nullable) annotations https://bugzilla.gnome.org/show_bug.cgi?id=771826
2016-09-22 11:56:47 +00:00
* Returns: (nullable) (transfer none): a #GdkDisplay or %NULL
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 *
gdk_gl_context_get_display (GdkGLContext *context)
{
g_return_val_if_fail (GDK_IS_GL_CONTEXT (context), NULL);
gdk: Turn GdkGLContext into a GdkDrawContext
2016-11-28 16:36:37 +00:00
return gdk_draw_context_get_display (GDK_DRAW_CONTEXT (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
}
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 various functions and variables This is an automatic rename of various things related to the window->surface rename. Public symbols changed by this is: GDK_MODE_WINDOW gdk_device_get_window_at_position gdk_device_get_window_at_position_double gdk_device_get_last_event_window gdk_display_get_monitor_at_window gdk_drag_context_get_source_window gdk_drag_context_get_dest_window gdk_drag_context_get_drag_window gdk_draw_context_get_window gdk_drawing_context_get_window gdk_gl_context_get_window gdk_synthesize_window_state gdk_surface_get_window_type gdk_x11_display_set_window_scale gsk_renderer_new_for_window gsk_renderer_get_window gtk_text_view_buffer_to_window_coords gtk_tree_view_convert_widget_to_bin_window_coords gtk_tree_view_convert_tree_to_bin_window_coords The commands that generated this are: git sed -f g "GDK window" "GDK surface" git sed -f g window_impl surface_impl (cd gdk; git sed -f g impl_window impl_surface) git sed -f g WINDOW_IMPL SURFACE_IMPL git sed -f g GDK_MODE_WINDOW GDK_MODE_SURFACE git sed -f g gdk_draw_context_get_window gdk_draw_context_get_surface git sed -f g gdk_drawing_context_get_window gdk_drawing_context_get_surface git sed -f g gdk_gl_context_get_window gdk_gl_context_get_surface git sed -f g gsk_renderer_get_window gsk_renderer_get_surface git sed -f g gsk_renderer_new_for_window gsk_renderer_new_for_surface (cd gdk; git sed -f g window_type surface_type) git sed -f g gdk_surface_get_window_type gdk_surface_get_surface_type git sed -f g window_at_position surface_at_position git sed -f g event_window event_surface git sed -f g window_coord surface_coord git sed -f g window_state surface_state git sed -f g window_cursor surface_cursor git sed -f g window_scale surface_scale git sed -f g window_events surface_events git sed -f g monitor_at_window monitor_at_surface git sed -f g window_under_pointer surface_under_pointer (cd gdk; git sed -f g for_window for_surface) git sed -f g window_anchor surface_anchor git sed -f g WINDOW_IS_TOPLEVEL SURFACE_IS_TOPLEVEL git sed -f g native_window native_surface git sed -f g source_window source_surface git sed -f g dest_window dest_surface git sed -f g drag_window drag_surface git sed -f g input_window input_surface git checkout NEWS* po-properties po docs/reference/gtk/migrating-3to4.xml
2018-03-20 11:05:26 +00:00
* gdk_gl_context_get_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
* @context: a #GdkGLContext
*
GdkWindow -> GdkSurface initial type rename This renames the GdkWindow class and related classes (impl, backend subclasses) to surface. Additionally it renames related types: GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType, GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge This is an automatic conversion using the below commands: git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass git sed -f g GdkWindow GdkSurface git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2" git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE" git sed -f g "broadway_window" "broadway_surface" git sed -f g "BroadwayWindow" "BroadwaySurface" git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE" git sed -f g "wayland_window" "wayland_surface" git sed -f g "WaylandWindow" "WaylandSurface" git sed -f g "X11_WINDOW" "X11_SURFACE" git sed -f g "x11_window" "x11_surface" git sed -f g "X11Window" "X11Surface" git sed -f g "WIN32_WINDOW" "WIN32_SURFACE" git sed -f g "win32_window" "win32_surface" git sed -f g "Win32Window" "Win32Surface" git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE" git sed -f g "quartz_window" "quartz_surface" git sed -f g "QuartzWindow" "QuartzSurface" git checkout NEWS* po-properties
2018-03-20 10:40:08 +00:00
* Retrieves the #GdkSurface used by the @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
*
GdkWindow -> GdkSurface initial type rename This renames the GdkWindow class and related classes (impl, backend subclasses) to surface. Additionally it renames related types: GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType, GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge This is an automatic conversion using the below commands: git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass git sed -f g GdkWindow GdkSurface git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2" git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE" git sed -f g "broadway_window" "broadway_surface" git sed -f g "BroadwayWindow" "BroadwaySurface" git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE" git sed -f g "wayland_window" "wayland_surface" git sed -f g "WaylandWindow" "WaylandSurface" git sed -f g "X11_WINDOW" "X11_SURFACE" git sed -f g "x11_window" "x11_surface" git sed -f g "X11Window" "X11Surface" git sed -f g "WIN32_WINDOW" "WIN32_SURFACE" git sed -f g "win32_window" "win32_surface" git sed -f g "Win32Window" "Win32Surface" git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE" git sed -f g "quartz_window" "quartz_surface" git sed -f g "QuartzWindow" "QuartzSurface" git checkout NEWS* po-properties
2018-03-20 10:40:08 +00:00
* Returns: (nullable) (transfer none): a #GdkSurface or %NULL
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
*/
GdkWindow -> GdkSurface initial type rename This renames the GdkWindow class and related classes (impl, backend subclasses) to surface. Additionally it renames related types: GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType, GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge This is an automatic conversion using the below commands: git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass git sed -f g GdkWindow GdkSurface git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2" git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE" git sed -f g "broadway_window" "broadway_surface" git sed -f g "BroadwayWindow" "BroadwaySurface" git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE" git sed -f g "wayland_window" "wayland_surface" git sed -f g "WaylandWindow" "WaylandSurface" git sed -f g "X11_WINDOW" "X11_SURFACE" git sed -f g "x11_window" "x11_surface" git sed -f g "X11Window" "X11Surface" git sed -f g "WIN32_WINDOW" "WIN32_SURFACE" git sed -f g "win32_window" "win32_surface" git sed -f g "Win32Window" "Win32Surface" git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE" git sed -f g "quartz_window" "quartz_surface" git sed -f g "QuartzWindow" "QuartzSurface" git checkout NEWS* po-properties
2018-03-20 10:40:08 +00:00
GdkSurface *
GdkSurface: Rename various functions and variables This is an automatic rename of various things related to the window->surface rename. Public symbols changed by this is: GDK_MODE_WINDOW gdk_device_get_window_at_position gdk_device_get_window_at_position_double gdk_device_get_last_event_window gdk_display_get_monitor_at_window gdk_drag_context_get_source_window gdk_drag_context_get_dest_window gdk_drag_context_get_drag_window gdk_draw_context_get_window gdk_drawing_context_get_window gdk_gl_context_get_window gdk_synthesize_window_state gdk_surface_get_window_type gdk_x11_display_set_window_scale gsk_renderer_new_for_window gsk_renderer_get_window gtk_text_view_buffer_to_window_coords gtk_tree_view_convert_widget_to_bin_window_coords gtk_tree_view_convert_tree_to_bin_window_coords The commands that generated this are: git sed -f g "GDK window" "GDK surface" git sed -f g window_impl surface_impl (cd gdk; git sed -f g impl_window impl_surface) git sed -f g WINDOW_IMPL SURFACE_IMPL git sed -f g GDK_MODE_WINDOW GDK_MODE_SURFACE git sed -f g gdk_draw_context_get_window gdk_draw_context_get_surface git sed -f g gdk_drawing_context_get_window gdk_drawing_context_get_surface git sed -f g gdk_gl_context_get_window gdk_gl_context_get_surface git sed -f g gsk_renderer_get_window gsk_renderer_get_surface git sed -f g gsk_renderer_new_for_window gsk_renderer_new_for_surface (cd gdk; git sed -f g window_type surface_type) git sed -f g gdk_surface_get_window_type gdk_surface_get_surface_type git sed -f g window_at_position surface_at_position git sed -f g event_window event_surface git sed -f g window_coord surface_coord git sed -f g window_state surface_state git sed -f g window_cursor surface_cursor git sed -f g window_scale surface_scale git sed -f g window_events surface_events git sed -f g monitor_at_window monitor_at_surface git sed -f g window_under_pointer surface_under_pointer (cd gdk; git sed -f g for_window for_surface) git sed -f g window_anchor surface_anchor git sed -f g WINDOW_IS_TOPLEVEL SURFACE_IS_TOPLEVEL git sed -f g native_window native_surface git sed -f g source_window source_surface git sed -f g dest_window dest_surface git sed -f g drag_window drag_surface git sed -f g input_window input_surface git checkout NEWS* po-properties po docs/reference/gtk/migrating-3to4.xml
2018-03-20 11:05:26 +00:00
gdk_gl_context_get_surface (GdkGLContext *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
{
g_return_val_if_fail (GDK_IS_GL_CONTEXT (context), NULL);
GdkSurface: Rename various functions and variables This is an automatic rename of various things related to the window->surface rename. Public symbols changed by this is: GDK_MODE_WINDOW gdk_device_get_window_at_position gdk_device_get_window_at_position_double gdk_device_get_last_event_window gdk_display_get_monitor_at_window gdk_drag_context_get_source_window gdk_drag_context_get_dest_window gdk_drag_context_get_drag_window gdk_draw_context_get_window gdk_drawing_context_get_window gdk_gl_context_get_window gdk_synthesize_window_state gdk_surface_get_window_type gdk_x11_display_set_window_scale gsk_renderer_new_for_window gsk_renderer_get_window gtk_text_view_buffer_to_window_coords gtk_tree_view_convert_widget_to_bin_window_coords gtk_tree_view_convert_tree_to_bin_window_coords The commands that generated this are: git sed -f g "GDK window" "GDK surface" git sed -f g window_impl surface_impl (cd gdk; git sed -f g impl_window impl_surface) git sed -f g WINDOW_IMPL SURFACE_IMPL git sed -f g GDK_MODE_WINDOW GDK_MODE_SURFACE git sed -f g gdk_draw_context_get_window gdk_draw_context_get_surface git sed -f g gdk_drawing_context_get_window gdk_drawing_context_get_surface git sed -f g gdk_gl_context_get_window gdk_gl_context_get_surface git sed -f g gsk_renderer_get_window gsk_renderer_get_surface git sed -f g gsk_renderer_new_for_window gsk_renderer_new_for_surface (cd gdk; git sed -f g window_type surface_type) git sed -f g gdk_surface_get_window_type gdk_surface_get_surface_type git sed -f g window_at_position surface_at_position git sed -f g event_window event_surface git sed -f g window_coord surface_coord git sed -f g window_state surface_state git sed -f g window_cursor surface_cursor git sed -f g window_scale surface_scale git sed -f g window_events surface_events git sed -f g monitor_at_window monitor_at_surface git sed -f g window_under_pointer surface_under_pointer (cd gdk; git sed -f g for_window for_surface) git sed -f g window_anchor surface_anchor git sed -f g WINDOW_IS_TOPLEVEL SURFACE_IS_TOPLEVEL git sed -f g native_window native_surface git sed -f g source_window source_surface git sed -f g dest_window dest_surface git sed -f g drag_window drag_surface git sed -f g input_window input_surface git checkout NEWS* po-properties po docs/reference/gtk/migrating-3to4.xml
2018-03-20 11:05:26 +00:00
return gdk_draw_context_get_surface (GDK_DRAW_CONTEXT (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
}
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
/**
* gdk_gl_context_get_shared_context:
* @context: a #GdkGLContext
*
* Retrieves the #GdkGLContext that this @context share data with.
*
Add some missing (nullable) annotations https://bugzilla.gnome.org/show_bug.cgi?id=771826
2016-09-22 11:56:47 +00:00
* Returns: (nullable) (transfer none): a #GdkGLContext or %NULL
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
*/
GdkGLContext *
gdk_gl_context_get_shared_context (GdkGLContext *context)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
g_return_val_if_fail (GDK_IS_GL_CONTEXT (context), NULL);
return priv->shared_context;
}
gl: Add gdk_gl_context_get_version() Store the OpenGL version when we first do the extensions check; this allows client code to check the available GL version without requiring a call to gdk_gl_context_make_current() and epoxy_gl_version().
2015-02-12 14:28:22 +00:00
/**
* gdk_gl_context_get_version:
* @context: a #GdkGLContext
* @major: (out): return location for the major version
* @minor: (out): return location for the minor version
*
* Retrieves the OpenGL version of the @context.
*
* The @context must be realized prior to calling this function.
*/
void
gdk_gl_context_get_version (GdkGLContext *context,
int *major,
int *minor)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (context);
g_return_if_fail (GDK_IS_GL_CONTEXT (context));
g_return_if_fail (priv->realized);
if (major != NULL)
*major = priv->gl_version / 10;
if (minor != NULL)
*minor = priv->gl_version % 10;
}
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_gl_context_clear_current:
*
* Clears the current #GdkGLContext.
*
* Any OpenGL call after this function returns will be ignored
* until gdk_gl_context_make_current() is called.
*/
void
gdk_gl_context_clear_current (void)
{
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
GdkGLContext *current;
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
current = g_private_get (&thread_current_context);
if (current != NULL)
{
gdk: Turn GdkGLContext into a GdkDrawContext
2016-11-28 16:36:37 +00:00
if (gdk_display_make_gl_context_current (gdk_draw_context_get_display (GDK_DRAW_CONTEXT (current)), 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
g_private_replace (&thread_current_context, NULL);
}
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
}
/**
* gdk_gl_context_get_current:
*
* Retrieves the current #GdkGLContext.
*
Add some missing (nullable) annotations https://bugzilla.gnome.org/show_bug.cgi?id=771826
2016-09-22 11:56:47 +00:00
* Returns: (nullable) (transfer none): the current #GdkGLContext, or %NULL
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
*/
GdkGLContext *
gdk_gl_context_get_current (void)
{
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
GdkGLContext *current;
current = g_private_get (&thread_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
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 current;
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: Add a gdk_gl_context_has_debug accessor Check if the label_object_ etc. functions are gonna do anything at all. The g_type_name_from_instance calls keep poppoing up in profiles.
2020-07-24 16:54:23 +00:00
gboolean
gdk_gl_context_has_debug (GdkGLContext *self)
{
GdkGLContextPrivate *priv = gdk_gl_context_get_instance_private (self);
return priv->debug_enabled || priv->use_khr_debug;
}
OpenGL/ES: Fix 'R' and 'B' bits inverted on Windows We need to use GL_BGRA instead of GL_RGBA when doing glReadPixels() on EGL on Windows (ANGLE) so that the red and blue bits won't be displayed inverted. Also fix the logic where we determine whether to bit blit or redraw everything.
2018-07-31 10:18:59 +00:00
/* This is currently private! */
/* When using GL/ES, don't flip the 'R' and 'B' bits on Windows/ANGLE for glReadPixels() */
gboolean
gdk_gl_context_use_es_bgra (GdkGLContext *context)
{
if (!gdk_gl_context_get_use_es (context))
return FALSE;
#ifdef GDK_WINDOWING_WIN32
if (GDK_WIN32_IS_GL_CONTEXT (context))
return TRUE;
#endif
return FALSE;
}
Reference in New Issue Copy Permalink