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

829 lines
28 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
Correct copyright year
2014-10-12 03:04:40 +00:00
* Copyright (C) 2014 Red Hat, Inc.
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
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser 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
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*/
#include "config.h"
#include "gdkcairo.h"
#include "gdkglcontextprivate.h"
#include "gdkinternals.h"
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 Direc3D 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. Note also that Visual Studio 2013 or later is required to build ANGLE from QT-5.10.1, but the 2013-built ANGLE DLLs can work without without problems for GTK+ that is built with Visual Studio 2008 or later. -Build libepoxy on Windows with EGL support enabled. -Define GDK_WIN32_ENABLE_EGL when building gdk-win32.lib when building with Visual Studio, or pass in --enable-win32-gles during configure when building with MinGW/mingw-w64. -Prior to running GTK+ programs, the GDK_GL envvar needs to contain gles. 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 is no plans to do this in this commit. Thanks to LRN for pointing out that we should #include "win32/gdkwin32.h" instead of #include "gdkwin32.h" for gdkgl.c. LRN also did the autotools portion of this patch. Further notes about the autotools --enable-win32-gles option, fom LRN: This adds --enable-win32-gles option, which enables the code for GLES renderer. This commit also adds tests for WGL and EGL in epoxy. The absence of WGL is highly unlikely (it's enabled by default), but checking for EGL when GLES is enabled is necessary, as EGL is disabled in Windows builds of epoxy by default.
2018-04-27 15:30:32 +00:00
#ifdef GDK_WINDOWING_WIN32
# include "win32/gdkwin32.h"
#endif
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 <epoxy/gl.h>
#include <math.h>
gdkgl: Texture quads in one giant draw call This requires us to use GL_TRIANGLES and six verts per quad instead of four, which makes me think it might not be worth it on well-optimized GL drivers. However, from talking to some driver developers about it, the GL_TRIANGLES should be faster, since this means that there's one giant contiguous buffer instead of many small buffers. If we were really rendering a lot of quads, I'd use an element buffer and GL_PRIMITIVE_RESTART, but we're really not ever rendering that many quads, and the setup cost for that would just be too annoying.
2014-11-22 18:17:22 +00:00
#include <string.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
static cairo_user_data_key_t direct_key;
void
gdk_cairo_surface_mark_as_direct (cairo_surface_t *surface,
GdkWindow *window)
{
cairo_surface_set_user_data (surface, &direct_key,
g_object_ref (window), g_object_unref);
}
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
static const char *
get_vertex_type_name (int type)
{
switch (type)
{
case GL_VERTEX_SHADER:
return "vertex";
case GL_GEOMETRY_SHADER:
return "geometry";
case GL_FRAGMENT_SHADER:
return "fragment";
}
return "unknown";
}
gdkgl: Make some helper functions static
2014-11-06 21:47:59 +00:00
static guint
Fix some clang warnings It complains about double const, and it is right.
2015-03-22 18:40:57 +00:00
create_shader (int type,
const char *code)
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 shader;
int status;
shader = glCreateShader (type);
glShaderSource (shader, 1, &code, NULL);
glCompileShader (shader);
glGetShaderiv (shader, GL_COMPILE_STATUS, &status);
if (status == GL_FALSE)
{
int log_len;
char *buffer;
glGetShaderiv (shader, GL_INFO_LOG_LENGTH, &log_len);
buffer = g_malloc (log_len + 1);
glGetShaderInfoLog (shader, log_len, NULL, buffer);
gdk: Strip newlines from g_warning and g_error g_logv adds one for us already.
2016-02-28 17:20:39 +00:00
g_warning ("Compile failure in %s shader:\n%s", get_vertex_type_name (type), buffer);
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
g_free (buffer);
glDeleteShader (shader);
return 0;
}
return shader;
}
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
static void
make_program (GdkGLContextProgram *program,
gdk: Move GLSL shaders into GResource Having the shaders inlined as C strings makes them harder to edit and maintain.
2016-04-22 11:34:33 +00:00
const char *vertex_shader_path,
const char *fragment_shader_path)
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
{
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
guint vertex_shader, fragment_shader;
gdk: Move GLSL shaders into GResource Having the shaders inlined as C strings makes them harder to edit and maintain.
2016-04-22 11:34:33 +00:00
GBytes *source;
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
int status;
gdk: Move GLSL shaders into GResource Having the shaders inlined as C strings makes them harder to edit and maintain.
2016-04-22 11:34:33 +00:00
source = g_resources_lookup_data (vertex_shader_path, 0, NULL);
g_assert (source != NULL);
vertex_shader = create_shader (GL_VERTEX_SHADER, g_bytes_get_data (source, NULL));
g_bytes_unref (source);
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
if (vertex_shader == 0)
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
return;
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
gdk: Move GLSL shaders into GResource Having the shaders inlined as C strings makes them harder to edit and maintain.
2016-04-22 11:34:33 +00:00
source = g_resources_lookup_data (fragment_shader_path, 0, NULL);
g_assert (source != NULL);
fragment_shader = create_shader (GL_FRAGMENT_SHADER, g_bytes_get_data (source, NULL));
g_bytes_unref (source);
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
if (fragment_shader == 0)
{
glDeleteShader (vertex_shader);
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
return;
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
}
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
program->program = glCreateProgram ();
glAttachShader (program->program, vertex_shader);
glAttachShader (program->program, fragment_shader);
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
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
glLinkProgram (program->program);
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
glDeleteShader (vertex_shader);
glDeleteShader (fragment_shader);
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
glGetProgramiv (program->program, GL_LINK_STATUS, &status);
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
if (status == GL_FALSE)
{
int log_len;
char *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
glGetProgramiv (program->program, GL_INFO_LOG_LENGTH, &log_len);
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
buffer = g_malloc (log_len + 1);
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
glGetProgramInfoLog (program->program, log_len, NULL, buffer);
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
g_warning ("Linker failure: %s\n", buffer);
g_free (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
glDeleteProgram (program->program);
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
}
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
program->position_location = glGetAttribLocation (program->program, "position");
program->uv_location = glGetAttribLocation (program->program, "uv");
program->map_location = glGetUniformLocation (program->program, "map");
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
program->flip_location = glGetUniformLocation (program->program, "flipColors");
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
}
static void
bind_vao (GdkGLContextPaintData *paint_data)
{
if (paint_data->vertex_array_object == 0)
{
glGenVertexArrays (1, &paint_data->vertex_array_object);
/* ATM we only use one VAO, so always bind it */
glBindVertexArray (paint_data->vertex_array_object);
}
}
gdk: Add GLES shaders We cannot use GL shaders with GLES.
2016-04-22 12:52:49 +00:00
static void
use_texture_gles_program (GdkGLContextPaintData *paint_data)
{
if (paint_data->texture_2d_quad_program.program == 0)
make_program (&paint_data->texture_2d_quad_program,
"/org/gtk/libgdk/glsl/gles2-texture.vs.glsl",
"/org/gtk/libgdk/glsl/gles2-texture.fs.glsl");
if (paint_data->current_program != &paint_data->texture_2d_quad_program)
{
paint_data->current_program = &paint_data->texture_2d_quad_program;
glUseProgram (paint_data->current_program->program);
}
}
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
static void
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
use_texture_2d_program (GdkGLContextPaintData *paint_data)
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
{
gdk: Move GLSL shaders into GResource Having the shaders inlined as C strings makes them harder to edit and maintain.
2016-04-22 11:34:33 +00:00
const char *vertex_shader_path = paint_data->is_legacy
? "/org/gtk/libgdk/glsl/gl2-texture-2d.vs.glsl"
: "/org/gtk/libgdk/glsl/gl3-texture-2d.vs.glsl";
const char *fragment_shader_path = paint_data->is_legacy
? "/org/gtk/libgdk/glsl/gl2-texture-2d.fs.glsl"
: "/org/gtk/libgdk/glsl/gl3-texture-2d.fs.glsl";
gl: Use older GLSL shaders with legacy contexts If we're using modern GLSL, then we should stop using deprecated modifiers, like 'varying' and 'attribute', as well as deprecated global variables, like 'gl_FragColor'. On the other hand, with legacy contexts we should be using older GLSL shaders, to maximize compatibility. https://bugzilla.gnome.org/show_bug.cgi?id=756142
2015-10-06 18:55:43 +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
if (paint_data->texture_2d_quad_program.program == 0)
gdk: Move GLSL shaders into GResource Having the shaders inlined as C strings makes them harder to edit and maintain.
2016-04-22 11:34:33 +00:00
make_program (&paint_data->texture_2d_quad_program, vertex_shader_path, fragment_shader_path);
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
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
if (paint_data->current_program != &paint_data->texture_2d_quad_program)
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
{
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
paint_data->current_program = &paint_data->texture_2d_quad_program;
glUseProgram (paint_data->current_program->program);
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
}
}
GdkGL: Fix up GL_ARB_texture_rectangle support This broke when gdk_gl_texture_quad moved to shaders. We need a specialized shader for the rectangle case.
2014-11-06 10:31:01 +00:00
static void
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
use_texture_rect_program (GdkGLContextPaintData *paint_data)
GdkGL: Fix up GL_ARB_texture_rectangle support This broke when gdk_gl_texture_quad moved to shaders. We need a specialized shader for the rectangle case.
2014-11-06 10:31:01 +00:00
{
gdk: Move GLSL shaders into GResource Having the shaders inlined as C strings makes them harder to edit and maintain.
2016-04-22 11:34:33 +00:00
const char *vertex_shader_path = paint_data->is_legacy
? "/org/gtk/libgdk/glsl/gl2-texture-rect.vs.glsl"
: "/org/gtk/libgdk/glsl/gl3-texture-rect.vs.glsl";
const char *fragment_shader_path = paint_data->is_legacy
? "/org/gtk/libgdk/glsl/gl2-texture-rect.fs.glsl"
: "/org/gtk/libgdk/glsl/gl3-texture-rect.vs.glsl";
GdkGL: Fix up GL_ARB_texture_rectangle support This broke when gdk_gl_texture_quad moved to shaders. We need a specialized shader for the rectangle case.
2014-11-06 10:31:01 +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
if (paint_data->texture_rect_quad_program.program == 0)
gdk: Move GLSL shaders into GResource Having the shaders inlined as C strings makes them harder to edit and maintain.
2016-04-22 11:34:33 +00:00
make_program (&paint_data->texture_rect_quad_program, vertex_shader_path, fragment_shader_path);
GdkGL: Fix up GL_ARB_texture_rectangle support This broke when gdk_gl_texture_quad moved to shaders. We need a specialized shader for the rectangle case.
2014-11-06 10:31:01 +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
if (paint_data->current_program != &paint_data->texture_rect_quad_program)
GdkGL: Fix up GL_ARB_texture_rectangle support This broke when gdk_gl_texture_quad moved to shaders. We need a specialized shader for the rectangle case.
2014-11-06 10:31:01 +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
paint_data->current_program = &paint_data->texture_rect_quad_program;
glUseProgram (paint_data->current_program->program);
GdkGL: Fix up GL_ARB_texture_rectangle support This broke when gdk_gl_texture_quad moved to shaders. We need a specialized shader for the rectangle case.
2014-11-06 10:31:01 +00:00
}
}
Add gdk_gl_texture_quad() helper Right now this just centralizes the glBegin/glEnd code, but this will be replaced with buffer objects later.
2014-11-05 14:42:06 +00:00
void
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
gdk_gl_texture_quads (GdkGLContext *paint_context,
guint texture_target,
int n_quads,
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
GdkTexturedQuad *quads,
gboolean flip_colors)
Add gdk_gl_texture_quad() helper Right now this just centralizes the glBegin/glEnd code, but this will be replaced with buffer objects later.
2014-11-05 14:42:06 +00:00
{
gdk/gdkgl.c: Fix Typo The extra ';' actually broke builds on C89 compilers...
2014-11-14 09:26:29 +00:00
GdkGLContextPaintData *paint_data = gdk_gl_context_get_paint_data (paint_context);
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 *program;
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
GdkWindow *window = gdk_gl_context_get_window (paint_context);
gdk_gl_texture_quad: Fix handling of window scales
2014-11-06 18:33:24 +00:00
int window_scale = gdk_window_get_scale_factor (window);
float w = gdk_window_get_width (window) * window_scale;
float h = gdk_window_get_height (window) * window_scale;
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
int i;
gdkgl: Texture quads in one giant draw call This requires us to use GL_TRIANGLES and six verts per quad instead of four, which makes me think it might not be worth it on well-optimized GL drivers. However, from talking to some driver developers about it, the GL_TRIANGLES should be faster, since this means that there's one giant contiguous buffer instead of many small buffers. If we were really rendering a lot of quads, I'd use an element buffer and GL_PRIMITIVE_RESTART, but we're really not ever rendering that many quads, and the setup cost for that would just be too annoying.
2014-11-22 18:17:22 +00:00
float *vertex_buffer_data;
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
bind_vao (paint_data);
if (paint_data->tmp_vertex_buffer == 0)
glGenBuffers(1, &paint_data->tmp_vertex_buffer);
gdk: Add GLES shaders We cannot use GL shaders with GLES.
2016-04-22 12:52:49 +00:00
if (paint_data->use_es)
use_texture_gles_program (paint_data);
GdkGL: Fix up GL_ARB_texture_rectangle support This broke when gdk_gl_texture_quad moved to shaders. We need a specialized shader for the rectangle case.
2014-11-06 10:31:01 +00:00
else
gdk: Add GLES shaders We cannot use GL shaders with GLES.
2016-04-22 12:52:49 +00:00
{
if (texture_target == GL_TEXTURE_RECTANGLE_ARB)
use_texture_rect_program (paint_data);
else
use_texture_2d_program (paint_data);
}
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
program = paint_data->current_program;
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
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
/* Use texture unit 0 */
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
glActiveTexture (GL_TEXTURE0);
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
glUniform1i(program->map_location, 0);
/* Flip 'R' and 'B' colors on GLES, if necessary */
if (gdk_gl_context_get_use_es (paint_context))
glUniform1i (program->flip_location, flip_colors ? 1 : 0);
GdkGL: Fix up GL_ARB_texture_rectangle support This broke when gdk_gl_texture_quad moved to shaders. We need a specialized shader for the rectangle case.
2014-11-06 10:31:01 +00:00
Fix core context creation in GdkGLContext - Specifically request GL version when creating context. Just specifying core profile bit results in the requested version defaulting to 1.0 which causes the core profile bit to be ignored and an arbitrary compatability context to be returned. - Fix GL painting by removing GL calls that have been depricated by the 3.2 core profile. - Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2 core. https://bugzilla.gnome.org/show_bug.cgi?id=742953
2015-01-15 01:30:28 +00:00
glEnableVertexAttribArray (program->position_location);
glEnableVertexAttribArray (program->uv_location);
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
glBindBuffer (GL_ARRAY_BUFFER, paint_data->tmp_vertex_buffer);
gdkgl: Use one VBO for both position and uv attributes
2014-11-22 18:12:58 +00:00
glVertexAttribPointer (program->position_location, 2, GL_FLOAT, GL_FALSE, sizeof(float) * 4, NULL);
gdkgl.c: Avoid GCCism in Pointer Arithmetic NULL-plus-something could be seen by the compiler to attempt to do arithmetic with void *, which is a GCCism. Instead, do the math normally and cast the results as a void *. https://bugzilla.gnome.org/show_bug.cgi?id=740605
2014-11-24 03:05:18 +00:00
glVertexAttribPointer (program->uv_location, 2, GL_FLOAT, GL_FALSE, sizeof(float) * 4, (void *) (sizeof(float) * 2));
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
gdkgl: Texture quads in one giant draw call This requires us to use GL_TRIANGLES and six verts per quad instead of four, which makes me think it might not be worth it on well-optimized GL drivers. However, from talking to some driver developers about it, the GL_TRIANGLES should be faster, since this means that there's one giant contiguous buffer instead of many small buffers. If we were really rendering a lot of quads, I'd use an element buffer and GL_PRIMITIVE_RESTART, but we're really not ever rendering that many quads, and the setup cost for that would just be too annoying.
2014-11-22 18:17:22 +00:00
#define VERTEX_SIZE 4
#define QUAD_N_VERTICES 6
#define QUAD_SIZE (VERTEX_SIZE * QUAD_N_VERTICES)
vertex_buffer_data = g_new (float, n_quads * QUAD_SIZE);
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
for (i = 0; i < n_quads; i++)
{
GdkTexturedQuad *quad = &quads[i];
gdkgl: Texture quads in one giant draw call This requires us to use GL_TRIANGLES and six verts per quad instead of four, which makes me think it might not be worth it on well-optimized GL drivers. However, from talking to some driver developers about it, the GL_TRIANGLES should be faster, since this means that there's one giant contiguous buffer instead of many small buffers. If we were really rendering a lot of quads, I'd use an element buffer and GL_PRIMITIVE_RESTART, but we're really not ever rendering that many quads, and the setup cost for that would just be too annoying.
2014-11-22 18:17:22 +00:00
float vertex_data[] = {
(quad->x1 * 2) / w - 1, (quad->y1 * 2) / h - 1, quad->u1, quad->v1,
(quad->x1 * 2) / w - 1, (quad->y2 * 2) / h - 1, quad->u1, quad->v2,
gdkgl: Use one VBO for both position and uv attributes
2014-11-22 18:12:58 +00:00
(quad->x2 * 2) / w - 1, (quad->y1 * 2) / h - 1, quad->u2, quad->v1,
gdkgl: Texture quads in one giant draw call This requires us to use GL_TRIANGLES and six verts per quad instead of four, which makes me think it might not be worth it on well-optimized GL drivers. However, from talking to some driver developers about it, the GL_TRIANGLES should be faster, since this means that there's one giant contiguous buffer instead of many small buffers. If we were really rendering a lot of quads, I'd use an element buffer and GL_PRIMITIVE_RESTART, but we're really not ever rendering that many quads, and the setup cost for that would just be too annoying.
2014-11-22 18:17:22 +00:00
gdkgl: Use one VBO for both position and uv attributes
2014-11-22 18:12:58 +00:00
(quad->x2 * 2) / w - 1, (quad->y2 * 2) / h - 1, quad->u2, quad->v2,
(quad->x1 * 2) / w - 1, (quad->y2 * 2) / h - 1, quad->u1, quad->v2,
gdkgl: Texture quads in one giant draw call This requires us to use GL_TRIANGLES and six verts per quad instead of four, which makes me think it might not be worth it on well-optimized GL drivers. However, from talking to some driver developers about it, the GL_TRIANGLES should be faster, since this means that there's one giant contiguous buffer instead of many small buffers. If we were really rendering a lot of quads, I'd use an element buffer and GL_PRIMITIVE_RESTART, but we're really not ever rendering that many quads, and the setup cost for that would just be too annoying.
2014-11-22 18:17:22 +00:00
(quad->x2 * 2) / w - 1, (quad->y1 * 2) / h - 1, quad->u2, quad->v1,
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
};
gdkgl: Texture quads in one giant draw call This requires us to use GL_TRIANGLES and six verts per quad instead of four, which makes me think it might not be worth it on well-optimized GL drivers. However, from talking to some driver developers about it, the GL_TRIANGLES should be faster, since this means that there's one giant contiguous buffer instead of many small buffers. If we were really rendering a lot of quads, I'd use an element buffer and GL_PRIMITIVE_RESTART, but we're really not ever rendering that many quads, and the setup cost for that would just be too annoying.
2014-11-22 18:17:22 +00:00
float *vertex = &vertex_buffer_data[i * QUAD_SIZE];
memcpy (vertex, vertex_data, sizeof(vertex_data));
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
}
gdkgl: Texture quads in one giant draw call This requires us to use GL_TRIANGLES and six verts per quad instead of four, which makes me think it might not be worth it on well-optimized GL drivers. However, from talking to some driver developers about it, the GL_TRIANGLES should be faster, since this means that there's one giant contiguous buffer instead of many small buffers. If we were really rendering a lot of quads, I'd use an element buffer and GL_PRIMITIVE_RESTART, but we're really not ever rendering that many quads, and the setup cost for that would just be too annoying.
2014-11-22 18:17:22 +00:00
glBufferData (GL_ARRAY_BUFFER, sizeof(float) * n_quads * QUAD_SIZE, vertex_buffer_data, GL_STREAM_DRAW);
glDrawArrays (GL_TRIANGLES, 0, n_quads * QUAD_N_VERTICES);
g_free (vertex_buffer_data);
Fix core context creation in GdkGLContext - Specifically request GL version when creating context. Just specifying core profile bit results in the requested version defaulting to 1.0 which causes the core profile bit to be ignored and an arbitrary compatability context to be returned. - Fix GL painting by removing GL calls that have been depricated by the 3.2 core profile. - Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2 core. https://bugzilla.gnome.org/show_bug.cgi?id=742953
2015-01-15 01:30:28 +00:00
glDisableVertexAttribArray (program->position_location);
glDisableVertexAttribArray (program->uv_location);
Add gdk_gl_texture_quad() helper Right now this just centralizes the glBegin/glEnd code, but this will be replaced with buffer objects later.
2014-11-05 14:42:06 +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
/* x,y,width,height describes a rectangle in the gl render buffer
coordinate space, and its top left corner is drawn at the current
position according to the cairo translation. */
Trivial formatting fixes
2014-10-12 03:17:34 +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
/**
Trivial formatting fixes
2014-10-12 03:17:34 +00:00
* gdk_cairo_draw_from_gl:
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
* @cr: a cairo context
* @window: The window we're rendering for (not necessarily into)
Trivial formatting fixes
2014-10-12 03:17:34 +00:00
* @source: The GL ID of the source buffer
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
* @source_type: The type of the @source
* @buffer_scale: The scale-factor that the @source buffer is allocated for
* @x: The source x position in @source to start copying from in GL coordinates
* @y: The source y position in @source to start copying from in GL coordinates
* @width: The width of the region to draw
* @height: The height of the region to draw
*
Trivial formatting fixes
2014-10-12 03:17:34 +00:00
* This is the main way to draw GL content in GTK+. It takes a render buffer ID
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
* (@source_type == #GL_RENDERBUFFER) or a texture id (@source_type == #GL_TEXTURE)
* and draws it onto @cr with an OVER operation, respecting the current clip.
Clarify docs for gdk_cairo_draw_from_gl
2014-10-30 11:22:08 +00:00
* The top left corner of the rectangle specified by @x, @y, @width and @height
* will be drawn at the current (0,0) position of the cairo_t.
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
*
* This will work for *all* cairo_t, as long as @window is realized, but the
* fallback implementation that reads back the pixels from the buffer may be
* used in the general case. In the case of direct drawing to a window with
* no special effects applied to @cr it will however use a more efficient
* approach.
*
* For #GL_RENDERBUFFER the code will always fall back to software for buffers
* with alpha components, so make sure you use #GL_TEXTURE if using alpha.
Trivial formatting fixes
2014-10-12 03:17:34 +00:00
*
gdk_cairo_draw_from_gl: Document that this changes the current context
2014-11-06 08:11:17 +00:00
* Calling this may change the current GL context.
*
Trivial formatting fixes
2014-10-12 03:17:34 +00:00
* Since: 3.16
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
*/
void
gdk_cairo_draw_from_gl (cairo_t *cr,
GdkWindow *window,
int source,
int source_type,
int buffer_scale,
int x,
int y,
int width,
int height)
{
GdkGL: Rename "context" to "paint_context" to clarify things a bit
2014-11-06 08:12:40 +00:00
GdkGLContext *paint_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
cairo_surface_t *image;
cairo_matrix_t matrix;
int dx, dy, window_scale;
gboolean trivial_transform;
cairo_surface_t *group_target;
GdkWindow *direct_window, *impl_window;
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
guint framebuffer;
int alpha_size = 0;
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
cairo_region_t *clip_region;
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
impl_window = window->impl_window;
window_scale = gdk_window_get_scale_factor (impl_window);
GdkGL: Rename "context" to "paint_context" to clarify things a bit
2014-11-06 08:12:40 +00:00
paint_context = gdk_window_get_paint_gl_context (window, NULL);
if (paint_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
{
g_warning ("gdk_cairo_draw_gl_render_buffer failed - no paint context");
return;
}
clip_region = gdk_cairo_region_from_clip (cr);
GdkGL: Rename "context" to "paint_context" to clarify things a bit
2014-11-06 08:12:40 +00:00
gdk_gl_context_make_current (paint_context);
paint_data = gdk_gl_context_get_paint_data (paint_context);
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
if (paint_data->tmp_framebuffer == 0)
Switch to GL_ARB_framebuffer_object GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is deprecated as the ARB version has been merged into OpenGL 3.0 as well as OpenGL ES 2.0, and provides laxer requirements.
2020-06-11 19:23:49 +00:00
glGenFramebuffers (1, &paint_data->tmp_framebuffer);
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
if (source_type == GL_RENDERBUFFER)
{
gl: Do not use the extension API for core GL Since we are using a Core GL profile, we need to drop the extension-based API. https://bugzilla.gnome.org/show_bug.cgi?id=741946
2015-01-28 19:06:37 +00:00
glBindRenderbuffer (GL_RENDERBUFFER, source);
GdkGL: Fix and clean up gdk_cairo_draw_from_gl() This was unnecessarily creating a framebuffer in the texture case, and it was not properly setting up a framebuffer with the texture as source in the software fallback w/ texture source case.
2014-11-05 08:52:51 +00:00
glGetRenderbufferParameteriv (GL_RENDERBUFFER, GL_RENDERBUFFER_ALPHA_SIZE, &alpha_size);
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
}
else if (source_type == GL_TEXTURE)
{
opengl: Use GL_TEXTURE_2D rather than GL_TEXTURE_RECTANGLE_ARB when possible This is more standard, and most driver support non-power-of-2 TEXTURE_2D these days. We fall back for ancient drivers.
2014-10-27 20:15:37 +00:00
glBindTexture (GL_TEXTURE_2D, source);
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 (gdk_gl_context_get_use_es (paint_context))
alpha_size = 1;
else
glGetTexLevelParameteriv (GL_TEXTURE_2D, 0, GL_TEXTURE_ALPHA_SIZE, &alpha_size);
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
}
else
{
g_warning ("Unsupported gl source type %d\n", source_type);
return;
}
group_target = cairo_get_group_target (cr);
direct_window = cairo_surface_get_user_data (group_target, &direct_key);
cairo_get_matrix (cr, &matrix);
dx = matrix.x0;
dy = matrix.y0;
/* Trivial == integer-only translation */
trivial_transform =
(double)dx == matrix.x0 && (double)dy == matrix.y0 &&
matrix.xx == 1.0 && matrix.xy == 0.0 &&
matrix.yx == 0.0 && matrix.yy == 1.0;
/* For direct paint of non-alpha renderbuffer, we can
just do a bitblit */
Export API to set GL flags This will be used in the inspector.
2014-11-07 04:29:16 +00:00
if ((_gdk_gl_flags & GDK_GL_SOFTWARE_DRAW_GL) == 0 &&
Add GDK_GL env var and GdkGLFlags This moves the GDK_ALWAYS_USE_GL env var to GDK_GL=always. It also changes GDK_DEBUG=nogl to GDK_GL=disable, as GDK_DEBUG is really only about debug loggin. It also adds some completely new flags: software-draw-gl: Always use software fallback for drawing gl content to a cairo_t. This disables the fastpaths that exist for drawing directly to a window and instead reads back the pixels into a cairo image surface. software-draw-surface: Always use software fallback for drawing cairo surfaces onto a gl-using window. This disables e.g. texture-from-pixmap on X11. software-draw: Enables both the above.
2014-11-06 09:21:48 +00:00
source_type == GL_RENDERBUFFER &&
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
alpha_size == 0 &&
direct_window != NULL &&
direct_window->current_paint.use_gl &&
gl: Check for GL_EXT_framebuffer_blit before using glBlitFramebuffer We check when we realize the GdkGLContext, but we never use the check before using the API, and it breaks on drivers that do not implement the extension, or on drivers that only support OpenGL ES 2.0.
2016-12-14 18:30:16 +00:00
gdk_gl_context_has_framebuffer_blit (paint_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
trivial_transform &&
clip_region != NULL)
{
GL: Fix GL Y coordinate flipping to use unscaled window height This is needed in the edge case where the X11 backend rounded the actual size, and the GL flipping really needs the correct window height to do proper Y coordinate flipping. https://bugzilla.gnome.org/show_bug.cgi?id=739750
2014-11-20 10:53:09 +00:00
int unscaled_window_height;
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
int i;
GdkGL: Fix and clean up gdk_cairo_draw_from_gl() This was unnecessarily creating a framebuffer in the texture case, and it was not properly setting up a framebuffer with the texture as source in the software fallback w/ texture source case.
2014-11-05 08:52:51 +00:00
/* Create a framebuffer with the source renderbuffer and
make it the current target for reads */
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
framebuffer = paint_data->tmp_framebuffer;
Switch to GL_ARB_framebuffer_object GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is deprecated as the ARB version has been merged into OpenGL 3.0 as well as OpenGL ES 2.0, and provides laxer requirements.
2020-06-11 19:23:49 +00:00
glBindFramebuffer (GL_FRAMEBUFFER, framebuffer);
glFramebufferRenderbuffer (GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
GL_RENDERBUFFER, source);
glBindFramebuffer (GL_DRAW_FRAMEBUFFER, 0);
GdkGL: Fix and clean up gdk_cairo_draw_from_gl() This was unnecessarily creating a framebuffer in the texture case, and it was not properly setting up a framebuffer with the texture as source in the software fallback w/ texture source case.
2014-11-05 08:52:51 +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
/* Translate to impl coords */
cairo_region_translate (clip_region, dx, dy);
glEnable (GL_SCISSOR_TEST);
GL: Fix GL Y coordinate flipping to use unscaled window height This is needed in the edge case where the X11 backend rounded the actual size, and the GL flipping really needs the correct window height to do proper Y coordinate flipping. https://bugzilla.gnome.org/show_bug.cgi?id=739750
2014-11-20 10:53:09 +00:00
gdk_window_get_unscaled_size (impl_window, NULL, &unscaled_window_height);
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: Use the appropriate formats when reading buffers on GLES We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back from the frame buffer in the software fallback path, as they do not exist on OpenGL ES. This will make the slow path a bit slower, because of the implicit format conversion.
2016-04-23 11:16:03 +00:00
/* We can use glDrawBuffer on OpenGL only; on GLES 2.0 we are already
* double buffered so we don't need 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
if (!gdk_gl_context_get_use_es (paint_context))
glDrawBuffer (GL_BACK);
else
{
int maj, min;
gdk_gl_context_get_version (paint_context, &maj, &min);
gl: Use the appropriate formats when reading buffers on GLES We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back from the frame buffer in the software fallback path, as they do not exist on OpenGL ES. This will make the slow path a bit slower, because of the implicit format conversion.
2016-04-23 11:16:03 +00:00
/* ... but on GLES 3.0 we can use the vectorized glDrawBuffers
* call.
*/
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 ((maj * 100 + min) >= 300)
{
static const GLenum buffers[] = { GL_BACK };
glDrawBuffers (G_N_ELEMENTS (buffers), 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
GL: Fix GL Y coordinate flipping to use unscaled window height This is needed in the edge case where the X11 backend rounded the actual size, and the GL flipping really needs the correct window height to do proper Y coordinate flipping. https://bugzilla.gnome.org/show_bug.cgi?id=739750
2014-11-20 10:53:09 +00:00
#define FLIP_Y(_y) (unscaled_window_height - (_y))
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
for (i = 0; i < cairo_region_num_rectangles (clip_region); i++)
{
cairo_rectangle_int_t clip_rect, dest;
cairo_region_get_rectangle (clip_region, i, &clip_rect);
clip_rect.x *= window_scale;
clip_rect.y *= window_scale;
clip_rect.width *= window_scale;
clip_rect.height *= window_scale;
glScissor (clip_rect.x, FLIP_Y (clip_rect.y + clip_rect.height),
clip_rect.width, clip_rect.height);
dest.x = dx * window_scale;
dest.y = dy * window_scale;
dest.width = width * window_scale / buffer_scale;
dest.height = height * window_scale / buffer_scale;
if (gdk_rectangle_intersect (&clip_rect, &dest, &dest))
{
int clipped_src_x = x + (dest.x - dx * window_scale);
int clipped_src_y = y + (height - dest.height - (dest.y - dy * window_scale));
Switch to GL_ARB_framebuffer_object GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is deprecated as the ARB version has been merged into OpenGL 3.0 as well as OpenGL ES 2.0, and provides laxer requirements.
2020-06-11 19:23:49 +00:00
glBlitFramebuffer (clipped_src_x, clipped_src_y,
(clipped_src_x + dest.width), (clipped_src_y + dest.height),
dest.x, FLIP_Y(dest.y + dest.height),
dest.x + dest.width, FLIP_Y(dest.y),
GL_COLOR_BUFFER_BIT, GL_NEAREST);
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
if (impl_window->current_paint.flushed_region)
{
cairo_rectangle_int_t flushed_rect;
flushed_rect.x = dest.x / window_scale;
flushed_rect.y = dest.y / window_scale;
flushed_rect.width = (dest.x + dest.width + window_scale - 1) / window_scale - flushed_rect.x;
flushed_rect.height = (dest.y + dest.height + window_scale - 1) / window_scale - flushed_rect.y;
cairo_region_union_rectangle (impl_window->current_paint.flushed_region,
&flushed_rect);
cairo_region_subtract_rectangle (impl_window->current_paint.need_blend_region,
&flushed_rect);
}
}
}
glDisable (GL_SCISSOR_TEST);
Switch to GL_ARB_framebuffer_object GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is deprecated as the ARB version has been merged into OpenGL 3.0 as well as OpenGL ES 2.0, and provides laxer requirements.
2020-06-11 19:23:49 +00:00
glBindFramebuffer (GL_FRAMEBUFFER, 0);
GdkGL: Fix and clean up gdk_cairo_draw_from_gl() This was unnecessarily creating a framebuffer in the texture case, and it was not properly setting up a framebuffer with the texture as source in the software fallback w/ texture source case.
2014-11-05 08:52:51 +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
#undef FLIP_Y
}
/* For direct paint of alpha or non-alpha textures we can use texturing */
Export API to set GL flags This will be used in the inspector.
2014-11-07 04:29:16 +00:00
else if ((_gdk_gl_flags & GDK_GL_SOFTWARE_DRAW_GL) == 0 &&
Add GDK_GL env var and GdkGLFlags This moves the GDK_ALWAYS_USE_GL env var to GDK_GL=always. It also changes GDK_DEBUG=nogl to GDK_GL=disable, as GDK_DEBUG is really only about debug loggin. It also adds some completely new flags: software-draw-gl: Always use software fallback for drawing gl content to a cairo_t. This disables the fastpaths that exist for drawing directly to a window and instead reads back the pixels into a cairo image surface. software-draw-surface: Always use software fallback for drawing cairo surfaces onto a gl-using window. This disables e.g. texture-from-pixmap on X11. software-draw: Enables both the above.
2014-11-06 09:21:48 +00:00
source_type == GL_TEXTURE &&
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
direct_window != NULL &&
direct_window->current_paint.use_gl &&
trivial_transform &&
clip_region != NULL)
{
GL: Fix GL Y coordinate flipping to use unscaled window height This is needed in the edge case where the X11 backend rounded the actual size, and the GL flipping really needs the correct window height to do proper Y coordinate flipping. https://bugzilla.gnome.org/show_bug.cgi?id=739750
2014-11-20 10:53:09 +00:00
int unscaled_window_height;
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
GLint texture_width;
GLint texture_height;
gdkgl: pass the correct number of quads to gdk_gl_texture_quads And call it only if that's the case
2014-12-02 13:59:47 +00:00
int i, n_rects, n_quads;
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
GdkTexturedQuad *quads;
cairo_rectangle_int_t clip_rect;
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
/* Translate to impl coords */
cairo_region_translate (clip_region, dx, dy);
if (alpha_size != 0)
{
cairo_region_t *opaque_region, *blend_region;
opaque_region = cairo_region_copy (clip_region);
cairo_region_subtract (opaque_region, impl_window->current_paint.flushed_region);
cairo_region_subtract (opaque_region, impl_window->current_paint.need_blend_region);
if (!cairo_region_is_empty (opaque_region))
gdk_gl_texture_from_surface (impl_window->current_paint.surface,
opaque_region);
blend_region = cairo_region_copy (clip_region);
cairo_region_intersect (blend_region, impl_window->current_paint.need_blend_region);
glEnable (GL_BLEND);
if (!cairo_region_is_empty (blend_region))
gdk_gl_texture_from_surface (impl_window->current_paint.surface,
blend_region);
cairo_region_destroy (opaque_region);
cairo_region_destroy (blend_region);
}
opengl: Use GL_TEXTURE_2D rather than GL_TEXTURE_RECTANGLE_ARB when possible This is more standard, and most driver support non-power-of-2 TEXTURE_2D these days. We fall back for ancient drivers.
2014-10-27 20:15:37 +00:00
glBindTexture (GL_TEXTURE_2D, source);
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 (gdk_gl_context_get_use_es (paint_context))
{
texture_width = width;
texture_height = height;
}
else
{
glGetTexLevelParameteriv (GL_TEXTURE_2D, 0, GL_TEXTURE_WIDTH, &texture_width);
glGetTexLevelParameteriv (GL_TEXTURE_2D, 0, GL_TEXTURE_HEIGHT, &texture_height);
}
opengl: Use GL_TEXTURE_2D rather than GL_TEXTURE_RECTANGLE_ARB when possible This is more standard, and most driver support non-power-of-2 TEXTURE_2D these days. We fall back for ancient drivers.
2014-10-27 20:15:37 +00:00
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
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
glEnable (GL_SCISSOR_TEST);
GL: Fix GL Y coordinate flipping to use unscaled window height This is needed in the edge case where the X11 backend rounded the actual size, and the GL flipping really needs the correct window height to do proper Y coordinate flipping. https://bugzilla.gnome.org/show_bug.cgi?id=739750
2014-11-20 10:53:09 +00:00
gdk_window_get_unscaled_size (impl_window, NULL, &unscaled_window_height);
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: Fix GL Y coordinate flipping to use unscaled window height This is needed in the edge case where the X11 backend rounded the actual size, and the GL flipping really needs the correct window height to do proper Y coordinate flipping. https://bugzilla.gnome.org/show_bug.cgi?id=739750
2014-11-20 10:53:09 +00:00
#define FLIP_Y(_y) (unscaled_window_height - (_y))
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: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
cairo_region_get_extents (clip_region, &clip_rect);
gdk_cairo_draw_from_gl - fix drawing with alpha on window scale > 1 The scissoring needs to take into account the window scale.
2014-12-15 20:54:11 +00:00
glScissor (clip_rect.x * window_scale, FLIP_Y ((clip_rect.y + clip_rect.height) * window_scale),
clip_rect.width * window_scale, clip_rect.height * window_scale);
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
gdkgl: pass the correct number of quads to gdk_gl_texture_quads And call it only if that's the case
2014-12-02 13:59:47 +00:00
n_quads = 0;
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
n_rects = cairo_region_num_rectangles (clip_region);
quads = g_new (GdkTexturedQuad, n_rects);
for (i = 0; i < n_rects; i++)
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
{
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
cairo_rectangle_int_t dest;
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
cairo_region_get_rectangle (clip_region, i, &clip_rect);
clip_rect.x *= window_scale;
clip_rect.y *= window_scale;
clip_rect.width *= window_scale;
clip_rect.height *= window_scale;
dest.x = dx * window_scale;
dest.y = dy * window_scale;
dest.width = width * window_scale / buffer_scale;
dest.height = height * window_scale / buffer_scale;
if (gdk_rectangle_intersect (&clip_rect, &dest, &dest))
{
int clipped_src_x = x + (dest.x - dx * window_scale);
int clipped_src_y = y + (height - dest.height - (dest.y - dy * window_scale));
gdkgl: Use a GdkTexturedQuad struct to paint quads We'll soon have a new function that paints multiple quads.
2014-11-22 17:39:18 +00:00
GdkTexturedQuad quad = {
dest.x, FLIP_Y(dest.y),
dest.x + dest.width, FLIP_Y(dest.y + dest.height),
clipped_src_x / (float)texture_width, (clipped_src_y + dest.height) / (float)texture_height,
(clipped_src_x + dest.width) / (float)texture_width, clipped_src_y / (float)texture_height,
};
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: pass the correct number of quads to gdk_gl_texture_quads And call it only if that's the case
2014-12-02 13:59:47 +00:00
quads[n_quads++] = quad;
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
if (impl_window->current_paint.flushed_region)
{
cairo_rectangle_int_t flushed_rect;
flushed_rect.x = dest.x / window_scale;
flushed_rect.y = dest.y / window_scale;
flushed_rect.width = (dest.x + dest.width + window_scale - 1) / window_scale - flushed_rect.x;
flushed_rect.height = (dest.y + dest.height + window_scale - 1) / window_scale - flushed_rect.y;
cairo_region_union_rectangle (impl_window->current_paint.flushed_region,
&flushed_rect);
cairo_region_subtract_rectangle (impl_window->current_paint.need_blend_region,
&flushed_rect);
}
}
}
gdkgl: pass the correct number of quads to gdk_gl_texture_quads And call it only if that's the case
2014-12-02 13:59:47 +00:00
if (n_quads > 0)
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
gdk_gl_texture_quads (paint_context, GL_TEXTURE_2D, n_quads, quads, FALSE);
gdkgl: pass the correct number of quads to gdk_gl_texture_quads And call it only if that's the case
2014-12-02 13:59:47 +00:00
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
g_free (quads);
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
if (alpha_size != 0)
glDisable (GL_BLEND);
#undef FLIP_Y
}
else
{
/* Software fallback */
gl: Use the appropriate formats when reading buffers on GLES We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back from the frame buffer in the software fallback path, as they do not exist on OpenGL ES. This will make the slow path a bit slower, because of the implicit format conversion.
2016-04-23 11:16:03 +00:00
int major, minor, version;
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 Direc3D 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. Note also that Visual Studio 2013 or later is required to build ANGLE from QT-5.10.1, but the 2013-built ANGLE DLLs can work without without problems for GTK+ that is built with Visual Studio 2008 or later. -Build libepoxy on Windows with EGL support enabled. -Define GDK_WIN32_ENABLE_EGL when building gdk-win32.lib when building with Visual Studio, or pass in --enable-win32-gles during configure when building with MinGW/mingw-w64. -Prior to running GTK+ programs, the GDK_GL envvar needs to contain gles. 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 is no plans to do this in this commit. Thanks to LRN for pointing out that we should #include "win32/gdkwin32.h" instead of #include "gdkwin32.h" for gdkgl.c. LRN also did the autotools portion of this patch. Further notes about the autotools --enable-win32-gles option, fom LRN: This adds --enable-win32-gles option, which enables the code for GLES renderer. This commit also adds tests for WGL and EGL in epoxy. The absence of WGL is highly unlikely (it's enabled by default), but checking for EGL when GLES is enabled is necessary, as EGL is disabled in Windows builds of epoxy by default.
2018-04-27 15:30:32 +00:00
gboolean es_read_bgra = FALSE;
#ifdef GDK_WINDOWING_WIN32
/* on ANGLE GLES, we need to set the glReadPixel() format as GL_BGRA instead */
if (GDK_WIN32_IS_GL_CONTEXT(paint_context))
es_read_bgra = TRUE;
#endif
gl: Use the appropriate formats when reading buffers on GLES We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back from the frame buffer in the software fallback path, as they do not exist on OpenGL ES. This will make the slow path a bit slower, because of the implicit format conversion.
2016-04-23 11:16:03 +00:00
gdk_gl_context_get_version (paint_context, &major, &minor);
version = major * 100 + minor;
/* TODO: Use glTexSubImage2D() and do a row-by-row copy to replace
* the GL_UNPACK_ROW_LENGTH support
*/
if (gdk_gl_context_get_use_es (paint_context) &&
!(version >= 300 || gdk_gl_context_has_unpack_subimage (paint_context)))
goto out;
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
/* TODO: avoid reading back non-required data due to dest clip */
image = cairo_surface_create_similar_image (cairo_get_target (cr),
(alpha_size == 0) ? CAIRO_FORMAT_RGB24 : CAIRO_FORMAT_ARGB32,
width, height);
cairo_surface_set_device_scale (image, buffer_scale, buffer_scale);
gdkgl: Don't constantly re-create the tmp framebuffer
2014-11-05 14:19:00 +00:00
framebuffer = paint_data->tmp_framebuffer;
Switch to GL_ARB_framebuffer_object GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is deprecated as the ARB version has been merged into OpenGL 3.0 as well as OpenGL ES 2.0, and provides laxer requirements.
2020-06-11 19:23:49 +00:00
glBindFramebuffer (GL_FRAMEBUFFER, framebuffer);
GdkGL: Fix and clean up gdk_cairo_draw_from_gl() This was unnecessarily creating a framebuffer in the texture case, and it was not properly setting up a framebuffer with the texture as source in the software fallback w/ texture source case.
2014-11-05 08:52:51 +00:00
if (source_type == GL_RENDERBUFFER)
{
/* Create a framebuffer with the source renderbuffer and
make it the current target for reads */
Switch to GL_ARB_framebuffer_object GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is deprecated as the ARB version has been merged into OpenGL 3.0 as well as OpenGL ES 2.0, and provides laxer requirements.
2020-06-11 19:23:49 +00:00
glFramebufferRenderbuffer (GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
GL_RENDERBUFFER, source);
GdkGL: Fix and clean up gdk_cairo_draw_from_gl() This was unnecessarily creating a framebuffer in the texture case, and it was not properly setting up a framebuffer with the texture as source in the software fallback w/ texture source case.
2014-11-05 08:52:51 +00:00
}
else
{
Switch to GL_ARB_framebuffer_object GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is deprecated as the ARB version has been merged into OpenGL 3.0 as well as OpenGL ES 2.0, and provides laxer requirements.
2020-06-11 19:23:49 +00:00
glFramebufferTexture2D (GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0,
GL_TEXTURE_2D, source, 0);
GdkGL: Fix and clean up gdk_cairo_draw_from_gl() This was unnecessarily creating a framebuffer in the texture case, and it was not properly setting up a framebuffer with the texture as source in the software fallback w/ texture source case.
2014-11-05 08:52:51 +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
glPixelStorei (GL_PACK_ALIGNMENT, 4);
glPixelStorei (GL_PACK_ROW_LENGTH, cairo_image_surface_get_stride (image) / 4);
gl: Use the appropriate formats when reading buffers on GLES We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back from the frame buffer in the software fallback path, as they do not exist on OpenGL ES. This will make the slow path a bit slower, because of the implicit format conversion.
2016-04-23 11:16:03 +00:00
/* The implicit format conversion is going to make this path slower */
if (!gdk_gl_context_get_use_es (paint_context))
glReadPixels (x, y, width, height, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV,
cairo_image_surface_get_data (image));
else
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 Direc3D 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. Note also that Visual Studio 2013 or later is required to build ANGLE from QT-5.10.1, but the 2013-built ANGLE DLLs can work without without problems for GTK+ that is built with Visual Studio 2008 or later. -Build libepoxy on Windows with EGL support enabled. -Define GDK_WIN32_ENABLE_EGL when building gdk-win32.lib when building with Visual Studio, or pass in --enable-win32-gles during configure when building with MinGW/mingw-w64. -Prior to running GTK+ programs, the GDK_GL envvar needs to contain gles. 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 is no plans to do this in this commit. Thanks to LRN for pointing out that we should #include "win32/gdkwin32.h" instead of #include "gdkwin32.h" for gdkgl.c. LRN also did the autotools portion of this patch. Further notes about the autotools --enable-win32-gles option, fom LRN: This adds --enable-win32-gles option, which enables the code for GLES renderer. This commit also adds tests for WGL and EGL in epoxy. The absence of WGL is highly unlikely (it's enabled by default), but checking for EGL when GLES is enabled is necessary, as EGL is disabled in Windows builds of epoxy by default.
2018-04-27 15:30:32 +00:00
glReadPixels (x, y, width, height, es_read_bgra ? GL_BGRA : GL_RGBA, GL_UNSIGNED_BYTE,
gl: Use the appropriate formats when reading buffers on GLES We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back from the frame buffer in the software fallback path, as they do not exist on OpenGL ES. This will make the slow path a bit slower, because of the implicit format conversion.
2016-04-23 11:16:03 +00:00
cairo_image_surface_get_data (image));
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
glPixelStorei (GL_PACK_ROW_LENGTH, 0);
Switch to GL_ARB_framebuffer_object GTK+ 3.0 was currently using GL_EXT_framebuffer_object, which is deprecated as the ARB version has been merged into OpenGL 3.0 as well as OpenGL ES 2.0, and provides laxer requirements.
2020-06-11 19:23:49 +00:00
glBindFramebuffer (GL_FRAMEBUFFER, 0);
GdkGL: Fix and clean up gdk_cairo_draw_from_gl() This was unnecessarily creating a framebuffer in the texture case, and it was not properly setting up a framebuffer with the texture as source in the software fallback w/ texture source case.
2014-11-05 08:52:51 +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
cairo_surface_mark_dirty (image);
/* Invert due to opengl having different origin */
cairo_scale (cr, 1, -1);
cairo_translate (cr, 0, -height / buffer_scale);
cairo_set_source_surface (cr, image, 0, 0);
cairo_set_operator (cr, CAIRO_OPERATOR_OVER);
cairo_paint (cr);
cairo_surface_destroy (image);
}
gl: Use the appropriate formats when reading buffers on GLES We cannot use GL_BGRA and GL_UNSIGNED_INT_8_8_8_8_REV when reading back from the frame buffer in the software fallback path, as they do not exist on OpenGL ES. This will make the slow path a bit slower, because of the implicit format conversion.
2016-04-23 11:16:03 +00:00
out:
gdk: Add support for OpenGL This adds the new type GdkGLContext that wraps an OpenGL context for a particular native window. It also adds support for the gdk paint machinery to use OpenGL to draw everything. As soon as anyone creates a GL context for a native window we create a "paint context" for that GdkWindow and switch to using GL for painting it. This commit contains only an implementation for X11 (using GLX). The way painting works is that all client gl contexts draw into offscreen buffers rather than directly to the back buffer, and the way something gets onto the window is by using gdk_cairo_draw_from_gl() to draw part of that buffer onto the draw cairo context. As a fallback (if we're doing redirected drawing or some effect like a cairo_push_group()) we read back the gl buffer into memory and composite using cairo. This means that GL rendering works in all cases, including rendering to a PDF. However, this is not particularly fast. In the *typical* case, where we're drawing directly to the window in the regular paint loop we hit the fast path. The fast path uses opengl to draw the buffer to the window back buffer, either by blitting or texturing. Then we track the region that was drawn, and when the draw ends we paint the normal cairo surface to the window (using texture-from-pixmap in the X11 case, or texture from cairo image otherwise) in the regions where there is no gl painted. There are some complexities wrt layering of gl and cairo areas though: * We track via gdk_window_mark_paint_from_clip() whenever gtk is painting over a region we previously rendered with opengl (flushed_region). This area (needs_blend_region) is blended rather than copied at the end of the frame. * If we're drawing a gl texture with alpha we first copy the current cairo_surface inside the target region to the back buffer before we blend over it. These two operations allow us full stacking of transparent gl and cairo regions.
2014-10-09 08:45:44 +00:00
if (clip_region)
cairo_region_destroy (clip_region);
Fix core context creation in GdkGLContext - Specifically request GL version when creating context. Just specifying core profile bit results in the requested version defaulting to 1.0 which causes the core profile bit to be ignored and an arbitrary compatability context to be returned. - Fix GL painting by removing GL calls that have been depricated by the 3.2 core profile. - Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2 core. https://bugzilla.gnome.org/show_bug.cgi?id=742953
2015-01-15 01:30:28 +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
}
GdkGL: Rename "context" to "paint_context" to clarify things a bit
2014-11-06 08:12:40 +00:00
/* This is always called with the paint context 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
void
gdk_gl_texture_from_surface (cairo_surface_t *surface,
Trivial formatting fixes
2014-10-12 03:17:34 +00:00
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: Rename "context" to "paint_context" to clarify things a bit
2014-11-06 08:12:40 +00:00
GdkGLContext *paint_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
cairo_surface_t *image;
double device_x_offset, device_y_offset;
cairo_rectangle_int_t rect, e;
int n_rects, i;
GdkWindow *window;
GL: Fix GL Y coordinate flipping to use unscaled window height This is needed in the edge case where the X11 backend rounded the actual size, and the GL flipping really needs the correct window height to do proper Y coordinate flipping. https://bugzilla.gnome.org/show_bug.cgi?id=739750
2014-11-20 10:53:09 +00:00
int unscaled_window_height;
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
unsigned int texture_id;
int window_scale;
double sx, sy;
opengl: Use GL_TEXTURE_2D rather than GL_TEXTURE_RECTANGLE_ARB when possible This is more standard, and most driver support non-power-of-2 TEXTURE_2D these days. We fall back for ancient drivers.
2014-10-27 20:15:37 +00:00
float umax, vmax;
gboolean use_texture_rectangle;
guint target;
GdkGL: Rename "context" to "paint_context" to clarify things a bit
2014-11-06 08:12:40 +00:00
paint_context = gdk_gl_context_get_current ();
Export API to set GL flags This will be used in the inspector.
2014-11-07 04:29:16 +00:00
if ((_gdk_gl_flags & GDK_GL_SOFTWARE_DRAW_SURFACE) == 0 &&
Add GDK_GL env var and GdkGLFlags This moves the GDK_ALWAYS_USE_GL env var to GDK_GL=always. It also changes GDK_DEBUG=nogl to GDK_GL=disable, as GDK_DEBUG is really only about debug loggin. It also adds some completely new flags: software-draw-gl: Always use software fallback for drawing gl content to a cairo_t. This disables the fastpaths that exist for drawing directly to a window and instead reads back the pixels into a cairo image surface. software-draw-surface: Always use software fallback for drawing cairo surfaces onto a gl-using window. This disables e.g. texture-from-pixmap on X11. software-draw: Enables both the above.
2014-11-06 09:21:48 +00:00
paint_context &&
GdkGL: Rename "context" to "paint_context" to clarify things a bit
2014-11-06 08:12:40 +00:00
GDK_GL_CONTEXT_GET_CLASS (paint_context)->texture_from_surface &&
GDK_GL_CONTEXT_GET_CLASS (paint_context)->texture_from_surface (paint_context, surface, 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
return;
/* Software fallback */
GdkGL: Rename "context" to "paint_context" to clarify things a bit
2014-11-06 08:12:40 +00:00
use_texture_rectangle = gdk_gl_context_use_texture_rectangle (paint_context);
opengl: Use GL_TEXTURE_2D rather than GL_TEXTURE_RECTANGLE_ARB when possible This is more standard, and most driver support non-power-of-2 TEXTURE_2D these days. We fall back for ancient drivers.
2014-10-27 20:15:37 +00:00
GdkGL: Rename "context" to "paint_context" to clarify things a bit
2014-11-06 08:12:40 +00:00
window = gdk_gl_context_get_window (paint_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
window_scale = gdk_window_get_scale_factor (window);
GL: Fix GL Y coordinate flipping to use unscaled window height This is needed in the edge case where the X11 backend rounded the actual size, and the GL flipping really needs the correct window height to do proper Y coordinate flipping. https://bugzilla.gnome.org/show_bug.cgi?id=739750
2014-11-20 10:53:09 +00:00
gdk_window_get_unscaled_size (window, NULL, &unscaled_window_height);
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
sx = sy = 1;
cairo_surface_get_device_scale (window->current_paint.surface, &sx, &sy);
cairo_surface_get_device_offset (surface,
&device_x_offset, &device_y_offset);
glGenTextures (1, &texture_id);
opengl: Use GL_TEXTURE_2D rather than GL_TEXTURE_RECTANGLE_ARB when possible This is more standard, and most driver support non-power-of-2 TEXTURE_2D these days. We fall back for ancient drivers.
2014-10-27 20:15:37 +00:00
if (use_texture_rectangle)
target = GL_TEXTURE_RECTANGLE_ARB;
else
target = GL_TEXTURE_2D;
glBindTexture (target, texture_id);
gdk_gl_texture_from_surface: Enable scissor test
2014-11-06 19:37:10 +00:00
glEnable (GL_SCISSOR_TEST);
opengl: Use GL_TEXTURE_2D rather than GL_TEXTURE_RECTANGLE_ARB when possible This is more standard, and most driver support non-power-of-2 TEXTURE_2D these days. We fall back for ancient drivers.
2014-10-27 20:15:37 +00:00
GdkGL: Fix up GL_ARB_texture_rectangle support This broke when gdk_gl_texture_quad moved to shaders. We need a specialized shader for the rectangle case.
2014-11-06 10:31:01 +00:00
glTexParameteri (target, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri (target, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri (target, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri (target, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
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
n_rects = cairo_region_num_rectangles (region);
gdkgl: Texture many quads at once for performance reasons This isn't fully performant yet. To be fully performant, we'd need to do everything in one giant buffer.
2014-11-22 17:47:35 +00:00
gdk: Fix scissoring with scaled windows Make sure the window scale is always taken into acount when setting up the scissor regions.
2014-12-15 21:31:48 +00:00
#define FLIP_Y(_y) (unscaled_window_height - (_y))
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
for (i = 0; i < n_rects; i++)
{
cairo_region_get_rectangle (region, i, &rect);
gdk: Fix scissoring with scaled windows Make sure the window scale is always taken into acount when setting up the scissor regions.
2014-12-15 21:31:48 +00:00
glScissor (rect.x * window_scale, FLIP_Y ((rect.y + rect.height) * window_scale),
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
rect.width * window_scale, rect.height * window_scale);
e = rect;
e.x *= sx;
e.y *= sy;
e.x += (int)device_x_offset;
e.y += (int)device_y_offset;
e.width *= sx;
e.height *= sy;
image = cairo_surface_map_to_image (surface, &e);
gl: Drop GdkGLContextClass.upload_texture() It's unnecessary to allow per-backend overrides.
2015-02-09 19:09:31 +00:00
gdk_gl_context_upload_texture (paint_context, image, e.width, e.height, target);
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
cairo_surface_unmap_image (surface, image);
opengl: Use GL_TEXTURE_2D rather than GL_TEXTURE_RECTANGLE_ARB when possible This is more standard, and most driver support non-power-of-2 TEXTURE_2D these days. We fall back for ancient drivers.
2014-10-27 20:15:37 +00:00
if (use_texture_rectangle)
{
umax = rect.width * sx;
vmax = rect.height * sy;
}
else
{
umax = 1.0;
vmax = 1.0;
}
gdkgl: Use a GdkTexturedQuad struct to paint quads We'll soon have a new function that paints multiple quads.
2014-11-22 17:39:18 +00:00
{
GdkTexturedQuad quad = {
gdk: Fix scissoring with scaled windows Make sure the window scale is always taken into acount when setting up the scissor regions.
2014-12-15 21:31:48 +00:00
rect.x * window_scale, FLIP_Y(rect.y * window_scale),
gdkgl: Use a GdkTexturedQuad struct to paint quads We'll soon have a new function that paints multiple quads.
2014-11-22 17:39:18 +00:00
(rect.x + rect.width) * window_scale, FLIP_Y((rect.y + rect.height) * window_scale),
0, 0,
umax, vmax,
};
gdk_gl_texture_from_surface - fix software fallback We can't combine multiple draws into one for the software fallback, because each quad has a different texture. And we generally don't want to make a larger single texture because then we would have to upload more data.
2014-12-15 20:55:10 +00:00
/* We don't want to combine the quads here, because they have different textures.
* And we don't want to upload the unused source areas to make it one texture. */
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
gdk_gl_texture_quads (paint_context, target, 1, &quad, TRUE);
gdkgl: Use a GdkTexturedQuad struct to paint quads We'll soon have a new function that paints multiple quads.
2014-11-22 17:39:18 +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
}
gl: Drop GdkGLContextClass.upload_texture() It's unnecessary to allow per-backend overrides.
2015-02-09 19:09:31 +00:00
#undef FLIP_Y
gdk_gl_texture_from_surface: Enable scissor test
2014-11-06 19:37:10 +00:00
glDisable (GL_SCISSOR_TEST);
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
glDeleteTextures (1, &texture_id);
}
Reference in New Issue Copy Permalink