AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-11-16 05:30:28 +00:00
Code Issues Projects Releases Wiki Activity
3d9a945803
gtk/gdk/gdkglcontextprivate.h

96 lines
3.7 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
*
* 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/>.
*/
#ifndef __GDK_GL_CONTEXT_PRIVATE_H__
#define __GDK_GL_CONTEXT_PRIVATE_H__
#include "gdkglcontext.h"
G_BEGIN_DECLS
#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
{
GObject parent_instance;
};
struct _GdkGLContextClass
{
GObjectClass parent_class;
GL: Split GL context creation in two phases One of the major requests by OpenGL users has been the ability to specify settings when creating a GL context, like the version to use or whether the debug support should be enabled. We have a couple of requirements in terms of API: • avoid, if at all possible, the "C arrays of integers with attribute, value pairs", which are hard to write and hard to bind in non-C languages. • allow failing in a recoverable way. • do not make the GL context creation API a mess of arguments. Looking at prior art, it seems that a common pattern is to split the construction phase in two: • a first phase that creates a GL context wrapper object and does preliminary checks on the environment. • a second phase that creates the backend-specific GL object. We adopted a similar pattern: • gdk_window_create_gl_context() creates a GdkGLContext • gdk_gl_context_realize() creates the underlying resources Calling gdk_gl_context_make_current() also realizes the context, so simple GL users do not need to care. Advanced users will want to call gdk_window_create_gl_context(), set up the optional requirements, and then call gdk_gl_context_realize(). If either of these two steps fails, it's possible to recover by changing the requirements, or simply creating a new GdkGLContext instance. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-27 21:23:23 +00:00
gboolean (* realize) (GdkGLContext *context,
GError **error);
Rename gdk_gl_context_flush_buffer to gdk_gl_context_end_frame This makes a lot more sense.
2014-10-27 15:33:37 +00:00
void (* end_frame) (GdkGLContext *context,
cairo_region_t *painted,
cairo_region_t *damage);
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
gboolean (* texture_from_surface) (GdkGLContext *context,
Rename gdk_gl_context_flush_buffer to gdk_gl_context_end_frame This makes a lot more sense.
2014-10-27 15:33:37 +00:00
cairo_surface_t *surface,
cairo_region_t *region);
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 {
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 vertex_array_object;
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
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: 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
void gdk_gl_context_set_is_legacy (GdkGLContext *context,
gboolean is_legacy);
gl: Drop GdkGLContextClass.upload_texture() It's unnecessary to allow per-backend overrides.
2015-02-09 19:09:31 +00:00
void gdk_gl_context_upload_texture (GdkGLContext *context,
cairo_surface_t *image_surface,
int width,
int height,
guint texture_target);
GdkGLContextPaintData * gdk_gl_context_get_paint_data (GdkGLContext *context);
gboolean gdk_gl_context_use_texture_rectangle (GdkGLContext *context);
gboolean gdk_gl_context_has_framebuffer_blit (GdkGLContext *context);
gboolean gdk_gl_context_has_frame_terminator (GdkGLContext *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
gboolean gdk_gl_context_has_unpack_subimage (GdkGLContext *context);
gl: Drop GdkGLContextClass.upload_texture() It's unnecessary to allow per-backend overrides.
2015-02-09 19:09:31 +00:00
void gdk_gl_context_end_frame (GdkGLContext *context,
cairo_region_t *painted,
cairo_region_t *damage);
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
G_END_DECLS
#endif /* __GDK_GL_CONTEXT_PRIVATE_H__ */
Reference in New Issue Copy Permalink