AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-12-26 13:41:07 +00:00
Code Issues Projects Releases Wiki Activity
0b9dfdd41f
gtk/gdk/gdkglcontextprivate.h

194 lines
9.1 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
*
* gdkglcontextprivate.h: GL context abstraction
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
*
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
* 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/>.
*/
Convert headers to #pragma once The conversion was done by guard2one.
2023-03-31 19:11:10 +00:00
#pragma once
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 "gdkglcontext.h"
gdk: Turn GdkGLContext into a GdkDrawContext
2016-11-28 16:36:37 +00:00
#include "gdkdrawcontextprivate.h"
gdk: Introduce GdkGLVersion ... and use it. Makes the code simpler.
2023-04-25 17:17:07 +00:00
#include "gdkglversionprivate.h"
gl context: Add private dmabuf API Add API to import a dmabuf into a texture, and to export a texture to a dmabuf. All this is implemented using the relevant EGL and GL extensions.
2023-10-15 23:27:22 +00:00
#include "gdkdmabufprivate.h"
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
G_BEGIN_DECLS
gl: Turn has_foo flags into GdkGLFeatures The goal is to have it mirror GdkVulkanFeatures, and in particular having an environment variable to turn individual flags off.
2024-03-16 10:31:17 +00:00
typedef enum {
GDK_GL_FEATURE_DEBUG = 1 << 0,
GDK_GL_FEATURE_UNPACK_SUBIMAGE = 1 << 1,
GDK_GL_FEATURE_VERTEX_HALF_FLOAT = 1 << 2,
GDK_GL_FEATURE_SYNC = 1 << 3,
gl: Move GL_ARB_base_instance check It's a GLContext feature check, not a GpuRenderer thing. So put it there.
2024-03-16 12:33:13 +00:00
GDK_GL_FEATURE_BASE_INSTANCE = 1 << 4,
gl: Add buffer implementation using persistent mapping If glBufferStorage() is available, we can replace our usage of glBufferSubData() with persistently mapped storage via glMappedBufferRange(). This has 1 disadvantage: 1. It's not supported everywhere, it requires GL 4.4 or GL_EXT_buffer_storage. But every GPU of the last 10 years should implement it. So we check for it and keep the old code. The old code can also be forced via GDK_GL_DISABLE=buffer-storage. But it has 2 advantages: 1. It is what Vulkan does, so it unifies the two renderers' buffer handling. 2. It is a significant performance boost in use cases with large vertex buffers. Those are pretty rare, but do happen with lots of text at a small font size. An example would be a small font in a maximized VTE terminal or the overview in gnome-text-editor. A custom benchmark tailored for this problem can be created with: tests/rendernode-create-tests 1000000 text.node This creates a node file called "text.node" that draws 1 million text nodes. (Creating that test takes a minute or so. A smaller number may be useful on less powerful hardware than my Intel Tigerlake laptop.) The difference can then be compared via: tools/gtk4-rendernode-tool benchmark --runs=20 text.node and GDK_GL_DISABLE=buffer-storage tools/gtk4-rendernode-tool benchmark --runs=20 text.node For my laptop, the difference is: before: 1.1s after: 0.8s Related: !7021
2024-03-16 19:19:38 +00:00
GDK_GL_FEATURE_BUFFER_STORAGE = 1 << 5,
gl: Turn has_foo flags into GdkGLFeatures The goal is to have it mirror GdkVulkanFeatures, and in particular having an environment variable to turn individual flags off.
2024-03-16 10:31:17 +00:00
} GdkGLFeatures;
gdk: Make sure only one GL backend is used Creative people managed to create an X11 display and a Wayland display at once, thereby getting EGL and GLX involved in a fight to the death over the ownership of the glFoo() symbolspace. A way to force such a fight with available tools here is (on Wayland) running something like: GTK_INSPECTOR_DISPLAY=:1 GTK_DEBUG=interactive gtk4-demo Related: xdg-desktop-portal-gnome#5
2021-09-23 23:47:03 +00:00
typedef enum {
GDK_GL_NONE = 0,
GDK_GL_EGL,
GDK_GL_GLX,
GDK_GL_WGL,
GDK_GL_CGL
} GdkGLBackend;
glcontext: Add gdk_gl_context_get_memory_flags() Checks which features of a given memory format are supported by the current GL implementation. We check: * usable: Can be used as a texture with NEAREST filter * renderable: Can be used as a render target * filterable: Can be used with GL_LINEAR In normal GL, all formats are all of these things, but GLES is a lot more picky. So far nobody uses this.
2023-12-07 04:45:59 +00:00
typedef enum {
/* The format is supported for glTexImage2D() */
GDK_GL_FORMAT_USABLE = 1 << 0,
/* The format can be rendered to.
* GL/GLES spec term: "color-renderable" */
GDK_GL_FORMAT_RENDERABLE = 1 << 1,
/* GL_LINEAR/GL_MIPMAP_LINEAR can be used for textures in this format.
* GLES spec term: "texture-filterable" */
GDK_GL_FORMAT_FILTERABLE = 1 << 2
} GdkGLMemoryFlags;
gl: Rewrite update area tracking code Make it more generic. That way we could dynamically change the number of buffers we track. We don't do that yet though.
2023-05-24 19:40:20 +00:00
/* The maximum amount of buffers we track update regions for.
* Note that this is equal to the max buffer age value we
* can provide a damage region for */
gl: Update tracked buffers from 2 to 4 With XWayland and direct scanout it is possible that some apps get into a situation where more than 2 buffers are in flight and in that case we want to be able to still track the change regions for those buffers. Usually 3 buffers are in use, so we go one higher, just to be safe.
2023-05-24 19:41:47 +00:00
#define GDK_GL_MAX_TRACKED_BUFFERS 4
gl: Rewrite update area tracking code Make it more generic. That way we could dynamically change the number of buffers we track. We don't do that yet though.
2023-05-24 19:40: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
#define GDK_GL_CONTEXT_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), GDK_TYPE_GL_CONTEXT, GdkGLContextClass))
#define GDK_IS_GL_CONTEXT_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), GDK_TYPE_GL_CONTEXT))
#define GDK_GL_CONTEXT_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GDK_TYPE_GL_CONTEXT, GdkGLContextClass))
typedef struct _GdkGLContextClass GdkGLContextClass;
struct _GdkGLContext
{
gdk: Turn GdkGLContext into a GdkDrawContext
2016-11-28 16:36:37 +00:00
GdkDrawContext parent_instance;
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
/* We store the old drawn areas to support buffer-age optimizations */
gl: Rewrite update area tracking code Make it more generic. That way we could dynamically change the number of buffers we track. We don't do that yet though.
2023-05-24 19:40:20 +00:00
cairo_region_t *old_updated_area[GDK_GL_MAX_TRACKED_BUFFERS];
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
};
struct _GdkGLContextClass
{
gdk: Turn GdkGLContext into a GdkDrawContext
2016-11-28 16:36:37 +00:00
GdkDrawContextClass parent_class;
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
gdk: Make sure only one GL backend is used Creative people managed to create an X11 display and a Wayland display at once, thereby getting EGL and GLX involved in a fight to the death over the ownership of the glFoo() symbolspace. A way to force such a fight with available tools here is (on Wayland) running something like: GTK_INSPECTOR_DISPLAY=:1 GTK_DEBUG=interactive gtk4-demo Related: xdg-desktop-portal-gnome#5
2021-09-23 23:47:03 +00:00
GdkGLBackend backend_type;
gl: Check allowed APIs in realize() Add gdk_gl_context_is_api_allowed() for backends and make them use it. Finally, have them return the final API as the return value (or 0 on error). And then use that api instead of a use_es boolean flag. Fixes #4221
2021-10-07 20:10:39 +00:00
GdkGLAPI (* realize) (GdkGLContext *context,
gdk: Add gdk_gl_context_is_shared() ... and use it in the GL renderers.
2021-06-30 02:52:35 +00:00
GError **error);
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
gl: Move vfunc Instead of Display::make_gl_context_current() we now have GLContext::clear_current() GLContext::make_current() This fits better with the backends (we can actually implement clearCurrent on macOS now) and makes it easier to implement different GL backends for backends (like EGL/GLX on X11). We also pass a surfaceless boolean to make_current() so the calling code can decide if a surface needs to be bound or not, because the backends were all doing whatever, which was very counterproductive.
2021-07-07 02:40:34 +00:00
gboolean (* make_current) (GdkGLContext *context,
gboolean surfaceless);
gboolean (* clear_current) (GdkGLContext *context);
gdk: Add private GLContext::is_current() check ... and use this check in gdk_gl_context_make_current() and gdk_gl_context_get_current() to make sure the context really is still current. The context no longer being current can happen when external GL implementations make their own contexts current in the same threads GDK contexts are used in. And that can happen for example by WebKit. Theoretically, this should also allow external EGL code to run in X11 applications when GDK chooses to use GLX, but I didn't try it. Fixes #5392
2023-02-02 01:49:56 +00:00
gboolean (* is_current) (GdkGLContext *context);
gdk: Add gdk_gl_context_is_shared() ... and use it in the GL renderers.
2021-06-30 02:52:35 +00:00
cairo_region_t * (* get_damage) (GdkGLContext *context);
gboolean (* is_shared) (GdkGLContext *self,
GdkGLContext *other);
gsk/gl: support non-standard default framebuffer There are situations where our "default framebuffer" is not actually zero, yet we still want to apply a scissor rect. Generally, 0 is the default framebuffer. But on platforms where we need to bind a platform-specific feature to a GL_FRAMEBUFFER, we might have a default that is not 0. For example, on macOS we bind an IOSurfaceRef to a GL_TEXTURE_RECTANGLE which then is assigned as the backing store for a framebuffer. This is different than using gsk_gl_renderer_render_texture() in that we don't want to incur an extra copy to the destination surface nor do we even have a way to pass a texture_id into render_texture().
2022-02-11 05:51:15 +00:00
guint (* get_default_framebuffer) (GdkGLContext *self);
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: Clean up program-manipulating code Abstract the program ID and locations into a "program struct" which we then use.
2014-11-22 17:29:27 +00:00
typedef struct {
guint program;
guint position_location;
guint uv_location;
guint map_location;
gl: Use a uniform to flip R and B colors on GLES This allows us to decide when the R and B color channels should be flipped with a much better granularity. For instance, when using GLX_EXT_texture_from_pixmap to create a GL texture from a surface we don't need to swap the R and B channels, as the internal representation of the texture data will already have the appropriate colors. We also don't need to flip color channels when blitting from a texture.
2016-04-25 12:38:22 +00:00
guint flip_location;
gdkgl: Clean up program-manipulating code Abstract the program ID and locations into a "program struct" which we then use.
2014-11-22 17:29:27 +00:00
} GdkGLContextProgram;
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
typedef struct {
guint tmp_framebuffer;
gdk_gl_texture_quad: Use shaders to texture things This is the modern way OpenGL works, and using it will let us switch to a core context for the paint context, and work on OpenGL ES 2.0.
2014-11-06 08:13:36 +00:00
guint tmp_vertex_buffer;
gdkgl: Clean up program-manipulating code Abstract the program ID and locations into a "program struct" which we then use.
2014-11-22 17:29:27 +00:00
GdkGLContextProgram texture_2d_quad_program;
GdkGLContextProgram texture_rect_quad_program;
GdkGLContextProgram *current_program;
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
guint is_legacy : 1;
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
guint use_es : 1;
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
} GdkGLContextPaintData;
gdk: Make sure only one GL backend is used Creative people managed to create an X11 display and a Wayland display at once, thereby getting EGL and GLX involved in a fight to the death over the ownership of the glFoo() symbolspace. A way to force such a fight with available tools here is (on Wayland) running something like: GTK_INSPECTOR_DISPLAY=:1 GTK_DEBUG=interactive gtk4-demo Related: xdg-desktop-portal-gnome#5
2021-09-23 23:47:03 +00:00
gboolean gdk_gl_backend_can_be_used (GdkGLBackend backend_type,
GError **error);
void gdk_gl_backend_use (GdkGLBackend backend_type);
gl: Clear current when destroying current's surface When destroying the EGLSurface or GLXDrawable of a GdkSurface, make sure the current context is not still bound to it. If it is, clear the current context. Fixes #4554
2021-12-22 18:49:13 +00:00
void gdk_gl_context_clear_current_if_surface (GdkSurface *surface);
API: Add gdk_display_create_gl_context() This is an alternative to gdk_surface_create_gl_context() when the context is meant to only draw to textures. This is useful in the testsuite or in GStreamer or with GLArea, basically whenever we want to do GL stuff but don't need to actually draw anything on screen. A bunch of code will need to be updated to deal with context->surface being NULL.
2021-10-20 18:03:00 +00:00
GdkGLContext * gdk_gl_context_new (GdkDisplay *display,
GdkSurface *surface);
gdk: Move GL context construction to GdkGLContext Now that we have the display's context to hook into, we can use it to construct other GL contexts and don't need a GdkSurface vfunc anymore. This has the added benefit that backends can have different GdkGLContext classes on the display and get new GLContexts generated from them, so we get multiple GL backend support per GDK backend for free. I originally wanted to make this a vfunc on GdkGLContextClass, but it turns out all the abckends would just call g_object_new() anyway.
2021-07-09 00:50:32 +00:00
egl: Make sure highest possible GL version is created The EGL spec states: The context returned must be the specified version, or a later version which is backwards compatible with that version. Even if a later version is returned, the specified version must correspond to a defined version of the client API. GTK has so far been relying on EGL implementations returning a later version, because that is what Mesa does. But ANGLE does not do that and only provides the minimum version, which means Windows EGL has been forced to use a lower EGL version for no reason. So fix this and try versions in order from highest to lowest.
2023-04-25 18:08:33 +00:00
gboolean gdk_gl_context_is_api_allowed (GdkGLContext *self,
GdkGLAPI api,
GError **error);
void gdk_gl_context_set_version (GdkGLContext *context,
const GdkGLVersion *version);
void gdk_gl_context_set_is_legacy (GdkGLContext *context,
gboolean is_legacy);
glcontext: Use GdkGLVersion elsewhere ... and add a convenience API to generate GL versions from strings to make the gdk_gl_context_check() API nicer.
2023-04-25 17:32:12 +00:00
gboolean gdk_gl_context_check_gl_version (GdkGLContext *context,
const GdkGLVersion *gl_version,
const GdkGLVersion *gles_version);
static inline gboolean
gdk_gl_context_check_version (GdkGLContext *context,
const char *gl_version,
const char *gles_version)
{
return gdk_gl_context_check_gl_version (context,
gl_version ? &GDK_GL_VERSION_STRING (gl_version) : NULL,
gles_version ? &GDK_GL_VERSION_STRING (gles_version) : NULL);
}
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
glcontext: Compute matching version the simple way Do it all in one function instead of requiring two different ones.
2023-04-25 19:45:31 +00:00
void gdk_gl_context_get_matching_version (GdkGLContext *context,
GdkGLAPI api,
gdk: Introduce GdkGLVersion ... and use it. Makes the code simpler.
2023-04-25 17:17:07 +00:00
gboolean legacy,
GdkGLVersion *out_version);
gl: Move texture uploading to the renderer It does not belong in GdkGLContext, it's a renderer thing. It's also the only user of that API. Introduce gdk_gl_context_check_version() private API to make version checks simpler.
2021-10-12 13:04:43 +00:00
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);
void gdk_gl_context_push_debug_group_printf (GdkGLContext *context,
Replace "gchar" with "char"
2020-07-24 18:40:36 +00:00
const char *format,
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_GNUC_PRINTF (2, 3);
void gdk_gl_context_pop_debug_group (GdkGLContext *context);
void gdk_gl_context_label_object (GdkGLContext *context,
guint identifier,
guint name,
const char *label);
void gdk_gl_context_label_object_printf (GdkGLContext *context,
guint identifier,
guint name,
const char *format,
...) G_GNUC_PRINTF (4, 5);
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
glcontext: Add gdk_gl_context_get_glsl_version_string() This is in preparation for the new renderer.
2023-08-29 10:59:26 +00:00
const char * gdk_gl_context_get_glsl_version_string (GdkGLContext *self);
glcontext: Add gdk_gl_context_get_memory_flags() Checks which features of a given memory format are supported by the current GL implementation. We check: * usable: Can be used as a texture with NEAREST filter * renderable: Can be used as a render target * filterable: Can be used with GL_LINEAR In normal GL, all formats are all of these things, but GLES is a lot more picky. So far nobody uses this.
2023-12-07 04:45:59 +00:00
GdkGLMemoryFlags gdk_gl_context_get_format_flags (GdkGLContext *self,
GdkMemoryFormat format) G_GNUC_PURE;
gl: Turn has_foo flags into GdkGLFeatures The goal is to have it mirror GdkVulkanFeatures, and in particular having an environment variable to turn individual flags off.
2024-03-16 10:31:17 +00:00
gboolean gdk_gl_context_has_feature (GdkGLContext *self,
GdkGLFeatures feature) G_GNUC_PURE;
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
gboolean gdk_gl_context_use_es_bgra (GdkGLContext *context);
glcontext: Add api to check for vertex arrays Vertex arrays are available in GL and in GLES >= 3. We don't check for the GLES extension that provided vertex arrays in older GLES, since that requires using different API. This api avoids version checks all over the place.
2023-10-20 00:56:59 +00:00
gboolean gdk_gl_context_has_vertex_arrays (GdkGLContext *self) G_GNUC_PURE;
Make fractional scaling for GL opt-in Fractional scaling with the GL renderer is experimental for now, so we disable it unless GDK_DEBUG=gl-fractional is set. This will give us time to work out the kinks.
2023-04-02 14:24:37 +00:00
double gdk_gl_context_get_scale (GdkGLContext *self);
gl context: Add private dmabuf API Add API to import a dmabuf into a texture, and to export a texture to a dmabuf. All this is implemented using the relevant EGL and GL extensions.
2023-10-15 23:27:22 +00:00
guint gdk_gl_context_import_dmabuf (GdkGLContext *self,
int width,
int height,
const GdkDmabuf *dmabuf,
dmabuf: Modify gdk_gl_context_import_dmabuf() Move a bunch of code - namely the target selection - into the function. I want to use the same code in the NGL renderer, so no need to duplicate it.
2023-11-02 01:51:41 +00:00
gboolean *external);
gl context: Add private dmabuf API Add API to import a dmabuf into a texture, and to export a texture to a dmabuf. All this is implemented using the relevant EGL and GL extensions.
2023-10-15 23:27:22 +00:00
gboolean gdk_gl_context_export_dmabuf (GdkGLContext *self,
unsigned int texture_id,
GdkDmabuf *dmabuf);
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 context: Add private dmabuf API Add API to import a dmabuf into a texture, and to export a texture to a dmabuf. All this is implemented using the relevant EGL and GL extensions.
2023-10-15 23:27:22 +00:00
G_END_DECLS
Reference in New Issue Copy Permalink