AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
a2f0c860ee
gtk2/gsk/gskglrenderer.c

1036 lines
31 KiB
C
Raw Normal View History

Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
#include "config.h"
#include "gskglrendererprivate.h"
#include "gskdebugprivate.h"
#include "gskenums.h"
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
#include "gskgldriverprivate.h"
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
#include "gskglprofilerprivate.h"
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#include "gskprofilerprivate.h"
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
#include "gskrendererprivate.h"
#include "gskrendernodeprivate.h"
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
#include "gskshaderbuilderprivate.h"
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
#include "gsktextureprivate.h"
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
#include "gskprivate.h"
#include <epoxy/gl.h>
gsk: Use the appropriate GLSL version The GLSL versions are: OpenGL 2.1: #version 110 OpenGL 3.0: #version 130 OpenGL 3.2: #version 150 OpenGLES 2.0: #version 100 OpenGLES 3.0: #version 300 es So we need to check the version of the GdkGLContext if we want use the appropriate version, especially for legacy OpenGL contexts, which can be both 3.x and 2.x.
2016-11-01 15:00:31 +00:00
#define SHADER_VERSION_GLES 100
#define SHADER_VERSION_GL2_LEGACY 110
#define SHADER_VERSION_GL3_LEGACY 130
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
#define SHADER_VERSION_GL3 150
gsk: Group render state attributes
2016-06-30 14:07:16 +00:00
typedef struct {
gsk: Rename uniforms and attributes in shaders Use appropriate names, and annotate the names with the types — 'u' for uniforms, 'a' for attributes. The common preambles for shaders are split from the bodies, so we need some way to distinguish the uniforms and the attributes just from their name.
2016-07-21 16:17:49 +00:00
int render_target_id;
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
int vao_id;
int buffer_id;
int texture_id;
int program_id;
int mvp_location;
gsk: Rename uniforms and attributes in shaders Use appropriate names, and annotate the names with the types — 'u' for uniforms, 'a' for attributes. The common preambles for shaders are split from the bodies, so we need some way to distinguish the uniforms and the attributes just from their name.
2016-07-21 16:17:49 +00:00
int source_location;
int mask_location;
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
int uv_location;
int position_location;
int alpha_location;
int blendMode_location;
gsk: Group render state attributes
2016-06-30 14:07:16 +00:00
} RenderData;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
typedef struct {
/* Back pointer to the node, only meant for comparison */
GskRenderNode *node;
graphene_point3d_t min;
graphene_point3d_t max;
graphene_size_t size;
graphene_matrix_t mvp;
float opacity;
float z;
const char *name;
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
GskBlendMode blend_mode;
gsk: Group render state attributes
2016-06-30 14:07:16 +00:00
RenderData render_data;
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
RenderData *parent_data;
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
GArray *children;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
} RenderItem;
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
enum {
MVP,
gsk: Rename uniforms and attributes in shaders Use appropriate names, and annotate the names with the types — 'u' for uniforms, 'a' for attributes. The common preambles for shaders are split from the bodies, so we need some way to distinguish the uniforms and the attributes just from their name.
2016-07-21 16:17:49 +00:00
SOURCE,
MASK,
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
ALPHA,
BLEND_MODE,
N_UNIFORMS
};
enum {
POSITION,
UV,
N_ATTRIBUTES
};
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#ifdef G_ENABLE_DEBUG
typedef struct {
GQuark frames;
GQuark draw_calls;
} ProfileCounters;
typedef struct {
GQuark cpu_time;
GQuark gpu_time;
} ProfileTimers;
#endif
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
typedef enum {
RENDER_FULL,
RENDER_SCISSOR
} RenderMode;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
struct _GskGLRenderer
{
GskRenderer parent_instance;
graphene_matrix_t mvp;
graphene_frustum_t frustum;
guint frame_buffer;
guint depth_stencil_buffer;
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
GQuark uniforms[N_UNIFORMS];
GQuark attributes[N_ATTRIBUTES];
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
GdkGLContext *gl_context;
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
GskGLDriver *gl_driver;
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
GskGLProfiler *gl_profiler;
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
GskShaderBuilder *shader_builder;
int blend_program_id;
gsk: Add 'blit' program For the root node we do not need to use blending, as it does not have any backdrop to blend into. We can use a simpler 'blit' program that only takes the content of the source and fills the texture quad with it.
2016-07-04 12:55:00 +00:00
int blit_program_id;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Drop opaque/transparent item split We're not going to use separate rendering lists soon, and the way we render items is less similar to a gaming engine and more similar to a simpler compositor. This means we don't need to perform a two pass rendering — opaque items first, transparent items later.
2016-07-21 16:19:53 +00:00
GArray *render_items;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#ifdef G_ENABLE_DEBUG
ProfileCounters profile_counters;
ProfileTimers profile_timers;
#endif
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
RenderMode render_mode;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gboolean has_buffers : 1;
};
struct _GskGLRendererClass
{
GskRendererClass parent_class;
};
G_DEFINE_TYPE (GskGLRenderer, gsk_gl_renderer, GSK_TYPE_RENDERER)
static void
gsk_gl_renderer_dispose (GObject *gobject)
{
GskGLRenderer *self = GSK_GL_RENDERER (gobject);
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
g_clear_object (&self->gl_context);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
G_OBJECT_CLASS (gsk_gl_renderer_parent_class)->dispose (gobject);
}
static void
gsk: Simplify buffer handling in GskGLRenderer We don't have optional stencil and depth buffers, like GtkGLArea: we always create both of them internally.
2016-07-19 13:42:54 +00:00
gsk_gl_renderer_create_buffers (GskGLRenderer *self,
int width,
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
int height,
int scale_factor)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
if (self->has_buffers)
return;
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
GSK_NOTE (OPENGL, g_print ("Creating buffers (w:%d, h:%d, scale:%d)\n", width, height, scale_factor));
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Simplify buffer handling in GskGLRenderer We don't have optional stencil and depth buffers, like GtkGLArea: we always create both of them internally.
2016-07-19 13:42:54 +00:00
self->has_buffers = TRUE;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
static void
gsk_gl_renderer_destroy_buffers (GskGLRenderer *self)
{
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
if (self->gl_context == NULL)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
return;
if (!self->has_buffers)
return;
GSK_NOTE (OPENGL, g_print ("Destroying buffers\n"));
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
gdk_gl_context_make_current (self->gl_context);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
self->has_buffers = FALSE;
}
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
static gboolean
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
gsk_gl_renderer_create_programs (GskGLRenderer *self,
GError **error)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
GskShaderBuilder *builder;
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
GError *shader_error = NULL;
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
gboolean res = FALSE;
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
builder = gsk_shader_builder_new ();
gsk_shader_builder_set_resource_base_path (builder, "/org/gtk/libgsk/glsl");
gsk: Rename uniforms and attributes in shaders Use appropriate names, and annotate the names with the types — 'u' for uniforms, 'a' for attributes. The common preambles for shaders are split from the bodies, so we need some way to distinguish the uniforms and the attributes just from their name.
2016-07-21 16:17:49 +00:00
self->uniforms[MVP] = gsk_shader_builder_add_uniform (builder, "uMVP");
self->uniforms[SOURCE] = gsk_shader_builder_add_uniform (builder, "uSource");
self->uniforms[MASK] = gsk_shader_builder_add_uniform (builder, "uMask");
self->uniforms[ALPHA] = gsk_shader_builder_add_uniform (builder, "uAlpha");
self->uniforms[BLEND_MODE] = gsk_shader_builder_add_uniform (builder, "uBlendMode");
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
gsk: Rename uniforms and attributes in shaders Use appropriate names, and annotate the names with the types — 'u' for uniforms, 'a' for attributes. The common preambles for shaders are split from the bodies, so we need some way to distinguish the uniforms and the attributes just from their name.
2016-07-21 16:17:49 +00:00
self->attributes[POSITION] = gsk_shader_builder_add_attribute (builder, "aPosition");
self->attributes[UV] = gsk_shader_builder_add_attribute (builder, "aUv");
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
if (gdk_gl_context_get_use_es (self->gl_context))
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
gsk_shader_builder_set_version (builder, SHADER_VERSION_GLES);
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
gsk_shader_builder_set_vertex_preamble (builder, "es2_common.vs.glsl");
gsk_shader_builder_set_fragment_preamble (builder, "es2_common.fs.glsl");
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
gsk_shader_builder_add_define (builder, "GSK_GLES", "1");
}
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
else if (gdk_gl_context_is_legacy (self->gl_context))
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
{
gsk: Use the appropriate GLSL version The GLSL versions are: OpenGL 2.1: #version 110 OpenGL 3.0: #version 130 OpenGL 3.2: #version 150 OpenGLES 2.0: #version 100 OpenGLES 3.0: #version 300 es So we need to check the version of the GdkGLContext if we want use the appropriate version, especially for legacy OpenGL contexts, which can be both 3.x and 2.x.
2016-11-01 15:00:31 +00:00
int maj, min;
gdk_gl_context_get_version (self->gl_context, &maj, &min);
if (maj == 3)
gsk_shader_builder_set_version (builder, SHADER_VERSION_GL3_LEGACY);
else
gsk_shader_builder_set_version (builder, SHADER_VERSION_GL2_LEGACY);
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
gsk_shader_builder_set_vertex_preamble (builder, "gl_common.vs.glsl");
gsk_shader_builder_set_fragment_preamble (builder, "gl_common.fs.glsl");
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
gsk_shader_builder_add_define (builder, "GSK_LEGACY", "1");
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
else
{
gsk_shader_builder_set_version (builder, SHADER_VERSION_GL3);
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
gsk_shader_builder_set_vertex_preamble (builder, "gl3_common.vs.glsl");
gsk_shader_builder_set_fragment_preamble (builder, "gl3_common.fs.glsl");
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
gsk_shader_builder_add_define (builder, "GSK_GL3", "1");
}
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
#ifdef G_ENABLE_DEBUG
if (GSK_RENDER_MODE_CHECK (SHADERS))
gsk_shader_builder_add_define (builder, "GSK_DEBUG", "1");
#endif
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
self->blend_program_id =
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
gsk_shader_builder_create_program (builder, "blend.vs.glsl", "blend.fs.glsl", &shader_error);
if (shader_error != NULL)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
g_propagate_prefixed_error (error,
shader_error,
"Unable to create 'blend' program: ");
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
g_object_unref (builder);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
goto out;
}
gsk: Add 'blit' program For the root node we do not need to use blending, as it does not have any backdrop to blend into. We can use a simpler 'blit' program that only takes the content of the source and fills the texture quad with it.
2016-07-04 12:55:00 +00:00
self->blit_program_id =
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
gsk_shader_builder_create_program (builder, "blit.vs.glsl", "blit.fs.glsl", &shader_error);
if (shader_error != NULL)
gsk: Add 'blit' program For the root node we do not need to use blending, as it does not have any backdrop to blend into. We can use a simpler 'blit' program that only takes the content of the source and fills the texture quad with it.
2016-07-04 12:55:00 +00:00
{
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
g_propagate_prefixed_error (error,
shader_error,
"Unable to create 'blit' program: ");
gsk: Add 'blit' program For the root node we do not need to use blending, as it does not have any backdrop to blend into. We can use a simpler 'blit' program that only takes the content of the source and fills the texture quad with it.
2016-07-04 12:55:00 +00:00
g_object_unref (builder);
goto out;
}
/* Keep a pointer to query for the uniform and attribute locations
* when rendering the scene
*/
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
self->shader_builder = builder;
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
res = TRUE;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
out:
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
return res;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
static void
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
gsk_gl_renderer_destroy_programs (GskGLRenderer *self)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
g_clear_object (&self->shader_builder);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
static gboolean
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
gsk_gl_renderer_realize (GskRenderer *renderer,
GdkWindow *window,
GError **error)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
GskGLRenderer *self = GSK_GL_RENDERER (renderer);
/* If we didn't get a GdkGLContext before realization, try creating
* one now, for our exclusive use.
*/
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
if (self->gl_context == NULL)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
self->gl_context = gdk_window_create_gl_context (window, error);
if (self->gl_context == NULL)
return FALSE;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
if (!gdk_gl_context_realize (self->gl_context, error))
return FALSE;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
gdk_gl_context_make_current (self->gl_context);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
g_assert (self->gl_driver == NULL);
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
self->gl_driver = gsk_gl_driver_new (self->gl_context);
self->gl_profiler = gsk_gl_profiler_new (self->gl_context);
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
GSK_NOTE (OPENGL, g_print ("Creating buffers and programs\n"));
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
if (!gsk_gl_renderer_create_programs (self, error))
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
return FALSE;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
return TRUE;
}
static void
gsk_gl_renderer_unrealize (GskRenderer *renderer)
{
GskGLRenderer *self = GSK_GL_RENDERER (renderer);
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
if (self->gl_context == NULL)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
return;
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
gdk_gl_context_make_current (self->gl_context);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
/* We don't need to iterate to destroy the associated GL resources,
* as they will be dropped when we finalize the GskGLDriver
*/
gsk: Drop opaque/transparent item split We're not going to use separate rendering lists soon, and the way we render items is less similar to a gaming engine and more similar to a simpler compositor. This means we don't need to perform a two pass rendering — opaque items first, transparent items later.
2016-07-21 16:19:53 +00:00
g_clear_pointer (&self->render_items, g_array_unref);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk_gl_renderer_destroy_buffers (self);
gsk: Rework how GLSL shaders are built The GL renderer should build the GLSL shaders using GskShaderBuilder. This allows us to separate the common parts into separate files, and assemble them as necessary, instead of shipping one big shader per type of GL API (GL3, GL legacy, and GLES).
2016-07-03 20:12:22 +00:00
gsk_gl_renderer_destroy_programs (self);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
g_clear_object (&self->gl_profiler);
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
g_clear_object (&self->gl_driver);
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
if (self->gl_context == gdk_gl_context_get_current ())
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gdk_gl_context_clear_current ();
}
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
static GdkDrawingContext *
gsk_gl_renderer_begin_draw_frame (GskRenderer *renderer,
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
const cairo_region_t *update_area)
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
{
GskGLRenderer *self = GSK_GL_RENDERER (renderer);
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
cairo_region_t *damage;
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
GdkDrawingContext *result;
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
GdkRectangle whole_window;
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
GdkWindow *window;
window = gsk_renderer_get_window (renderer);
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
whole_window = (GdkRectangle) {
0, 0,
gdk_window_get_width (window),
gdk_window_get_height (window)
};
damage = gdk_gl_context_get_damage (self->gl_context);
cairo_region_union (damage, update_area);
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
if (cairo_region_contains_rectangle (damage, &whole_window) == CAIRO_REGION_OVERLAP_IN)
{
self->render_mode = RENDER_FULL;
}
else
{
GdkRectangle extents;
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
cairo_region_get_extents (damage, &extents);
cairo_region_union_rectangle (damage, &extents);
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
if (gdk_rectangle_equal (&extents, &whole_window))
self->render_mode = RENDER_FULL;
else
self->render_mode = RENDER_SCISSOR;
}
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
result = gdk_window_begin_draw_frame (window,
GDK_DRAW_CONTEXT (self->gl_context),
damage);
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
cairo_region_destroy (damage);
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
return result;
}
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
static void
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk_gl_renderer_resize_viewport (GskGLRenderer *self,
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
const graphene_rect_t *viewport,
int scale_factor)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
int width = viewport->size.width * scale_factor;
int height = viewport->size.height * scale_factor;
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
GSK_NOTE (OPENGL, g_print ("glViewport(0, 0, %d, %d) [scale:%d]\n",
width,
height,
scale_factor));
glViewport (0, 0, width, height);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
static void
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk_gl_renderer_update_frustum (GskGLRenderer *self,
const graphene_matrix_t *modelview,
const graphene_matrix_t *projection)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gsk: Split of debug spew for transforms This was overwhelming other useful debug output, so make it opt-in. We print the render items for both opengl and transforms, since the matrices bleed into each other, otherwise.
2016-08-03 02:00:50 +00:00
GSK_NOTE (TRANSFORMS, g_print ("Updating the modelview/projection\n"));
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Fix hidpi scaling We store the vertices in (unscaled) window coords (but the item size is still scaled to match the texture size). Also, the projection/model-view multiplication order is switched so that the scale is applied at the right place.
2016-08-16 10:44:39 +00:00
graphene_matrix_multiply (modelview, projection, &self->mvp);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
graphene_frustum_init_from_matrix (&self->frustum, &self->mvp);
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
gsk: Split of debug spew for transforms This was overwhelming other useful debug output, so make it opt-in. We print the render items for both opengl and transforms, since the matrices bleed into each other, otherwise.
2016-08-03 02:00:50 +00:00
GSK_NOTE (TRANSFORMS,
g_print ("Renderer MVP:\n");
graphene_matrix_print (&self->mvp);
g_print ("\n"));
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
#define N_VERTICES 6
static void
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
render_item (GskGLRenderer *self,
RenderItem *item)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
float mvp[16];
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
float opacity;
if (item->children != NULL)
{
if (gsk_gl_driver_bind_render_target (self->gl_driver, item->render_data.render_target_id))
{
glViewport (0, 0, item->size.width, item->size.height);
glClearColor (0.0, 0.0, 0.0, 0.0);
glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
}
}
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
gsk_gl_driver_bind_vao (self->gl_driver, item->render_data.vao_id);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Group render state attributes
2016-06-30 14:07:16 +00:00
glUseProgram (item->render_data.program_id);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
if (item->render_data.texture_id != 0)
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
{
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
/* Use texture unit 0 for the source */
glUniform1i (item->render_data.source_location, 0);
gsk_gl_driver_bind_source_texture (self->gl_driver, item->render_data.texture_id);
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
if (item->parent_data != NULL)
gsk: Rename uniforms and attributes in shaders Use appropriate names, and annotate the names with the types — 'u' for uniforms, 'a' for attributes. The common preambles for shaders are split from the bodies, so we need some way to distinguish the uniforms and the attributes just from their name.
2016-07-21 16:17:49 +00:00
{
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
glUniform1i (item->render_data.blendMode_location, item->blend_mode);
/* Use texture unit 1 for the mask */
if (item->parent_data->texture_id != 0)
{
glUniform1i (item->render_data.mask_location, 1);
gsk_gl_driver_bind_mask_texture (self->gl_driver, item->parent_data->texture_id);
}
gsk: Rename uniforms and attributes in shaders Use appropriate names, and annotate the names with the types — 'u' for uniforms, 'a' for attributes. The common preambles for shaders are split from the bodies, so we need some way to distinguish the uniforms and the attributes just from their name.
2016-07-21 16:17:49 +00:00
}
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
}
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
/* Pass the opacity component */
gsk: Remove gsk_render_node_set_opaque() If we ever feel, we need this function again, we can readd it later. But nobody is using it other than for overriding opactiy. And you can just override opacity directly if you care.
2016-12-11 10:48:32 +00:00
if (item->children != NULL)
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
opacity = 1.0;
else
opacity = item->opacity;
glUniform1f (item->render_data.alpha_location, opacity);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
/* Pass the mvp to the vertex shader */
gsk: Split of debug spew for transforms This was overwhelming other useful debug output, so make it opt-in. We print the render items for both opengl and transforms, since the matrices bleed into each other, otherwise.
2016-08-03 02:00:50 +00:00
GSK_NOTE (TRANSFORMS, graphene_matrix_print (&item->mvp));
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
graphene_matrix_to_float (&item->mvp, mvp);
gsk: Group render state attributes
2016-06-30 14:07:16 +00:00
glUniformMatrix4fv (item->render_data.mvp_location, 1, GL_FALSE, mvp);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
/* Draw the quad */
gsk: Split of debug spew for transforms This was overwhelming other useful debug output, so make it opt-in. We print the render items for both opengl and transforms, since the matrices bleed into each other, otherwise.
2016-08-03 02:00:50 +00:00
GSK_NOTE2 (OPENGL, TRANSFORMS,
gsk: Remove GskRenderNode::parent ... and all related APIs.
2016-12-12 17:54:49 +00:00
g_print ("Drawing item <%s>[%p] (w:%g, h:%g) with opacity: %g blend mode: %d\n",
gsk: Split of debug spew for transforms This was overwhelming other useful debug output, so make it opt-in. We print the render items for both opengl and transforms, since the matrices bleed into each other, otherwise.
2016-08-03 02:00:50 +00:00
item->name,
item,
item->size.width, item->size.height,
gsk: Remove gsk_render_node_set_opaque() If we ever feel, we need this function again, we can readd it later. But nobody is using it other than for overriding opactiy. And you can just override opacity directly if you care.
2016-12-11 10:48:32 +00:00
item->opacity,
Add blend mode to debug spew
2016-08-13 08:07:38 +00:00
item->blend_mode));
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
glDrawArrays (GL_TRIANGLES, 0, N_VERTICES);
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#ifdef G_ENABLE_DEBUG
gsk_profiler_counter_inc (gsk_renderer_get_profiler (GSK_RENDERER (self)),
self->profile_counters.draw_calls);
#endif
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
/* Render all children items, so we can take the result
* render target texture during the compositing
*/
if (item->children != NULL)
{
int i;
for (i = 0; i < item->children->len; i++)
{
RenderItem *child = &g_array_index (item->children, RenderItem, i);
render_item (self, child);
}
/* Bind the parent render target */
if (item->parent_data != NULL)
gsk_gl_driver_bind_render_target (self->gl_driver, item->parent_data->render_target_id);
/* Bind the same VAO, as the render target is created with the same size
* and vertices as the texture target
*/
gsk_gl_driver_bind_vao (self->gl_driver, item->render_data.vao_id);
/* Since we're rendering the target texture, we only need the blit program */
glUseProgram (self->blit_program_id);
/* Use texture unit 0 for the render target */
glUniform1i (item->render_data.source_location, 0);
gsk_gl_driver_bind_source_texture (self->gl_driver, item->render_data.render_target_id);
/* Pass the opacity component; if we got here, we know that the original render
* target is neither fully opaque nor at full opacity
*/
glUniform1f (item->render_data.alpha_location, item->opacity);
/* Pass the mvp to the vertex shader */
gsk: Split of debug spew for transforms This was overwhelming other useful debug output, so make it opt-in. We print the render items for both opengl and transforms, since the matrices bleed into each other, otherwise.
2016-08-03 02:00:50 +00:00
GSK_NOTE (TRANSFORMS, graphene_matrix_print (&item->mvp));
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
graphene_matrix_to_float (&item->mvp, mvp);
glUniformMatrix4fv (item->render_data.mvp_location, 1, GL_FALSE, mvp);
/* Draw the quad */
gsk: Split of debug spew for transforms This was overwhelming other useful debug output, so make it opt-in. We print the render items for both opengl and transforms, since the matrices bleed into each other, otherwise.
2016-08-03 02:00:50 +00:00
GSK_NOTE2 (OPENGL, TRANSFORMS,
gsk: Remove GskRenderNode::parent ... and all related APIs.
2016-12-12 17:54:49 +00:00
g_print ("Drawing offscreen item <%s>[%p] (w:%g, h:%g) with opacity: %g\n",
gsk: Split of debug spew for transforms This was overwhelming other useful debug output, so make it opt-in. We print the render items for both opengl and transforms, since the matrices bleed into each other, otherwise.
2016-08-03 02:00:50 +00:00
item->name,
item,
item->size.width, item->size.height,
item->opacity));
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
glDrawArrays (GL_TRIANGLES, 0, N_VERTICES);
}
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
static void
gsk: Move scaling filters to GskRenderNode The renderer will always use nearest-neighbor filters because it renders at 1:1 pixel to texel ratio. On the other hand, render nodes may be scaled, so we need to offer a way to control the minification and magnification filters.
2016-08-13 07:34:22 +00:00
get_gl_scaling_filters (GskRenderNode *node,
int *min_filter_r,
int *mag_filter_r)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gsk: Move scaling filters to GskRenderNode The renderer will always use nearest-neighbor filters because it renders at 1:1 pixel to texel ratio. On the other hand, render nodes may be scaled, so we need to offer a way to control the minification and magnification filters.
2016-08-13 07:34:22 +00:00
switch (node->min_filter)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
case GSK_SCALING_FILTER_NEAREST:
*min_filter_r = GL_NEAREST;
break;
case GSK_SCALING_FILTER_LINEAR:
*min_filter_r = GL_LINEAR;
break;
case GSK_SCALING_FILTER_TRILINEAR:
*min_filter_r = GL_LINEAR_MIPMAP_LINEAR;
break;
}
gsk: Move scaling filters to GskRenderNode The renderer will always use nearest-neighbor filters because it renders at 1:1 pixel to texel ratio. On the other hand, render nodes may be scaled, so we need to offer a way to control the minification and magnification filters.
2016-08-13 07:34:22 +00:00
switch (node->mag_filter)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
case GSK_SCALING_FILTER_NEAREST:
*mag_filter_r = GL_NEAREST;
break;
/* There's no point in using anything above GL_LINEAR for
* magnification filters
*/
case GSK_SCALING_FILTER_LINEAR:
case GSK_SCALING_FILTER_TRILINEAR:
*mag_filter_r = GL_LINEAR;
break;
}
}
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
#if 0
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
static gboolean
check_in_frustum (const graphene_frustum_t *frustum,
RenderItem *item)
{
graphene_box_t aabb;
graphene_box_init (&aabb, &item->min, &item->max);
graphene_matrix_transform_box (&item->mvp, &aabb, &aabb);
return graphene_frustum_intersects_box (frustum, &aabb);
}
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
#endif
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
static float
project_item (const graphene_matrix_t *projection,
const graphene_matrix_t *modelview)
{
graphene_vec4_t vec;
graphene_matrix_get_row (modelview, 3, &vec);
graphene_matrix_transform_vec4 (projection, &vec, &vec);
return graphene_vec4_get_z (&vec) / graphene_vec4_get_w (&vec);
}
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
static gboolean
render_node_needs_render_target (GskRenderNode *node)
{
return FALSE;
}
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
static void
gsk: Drop modelview/projection from GskRenderer API The details of the modelview and projection matrices are only useful for the GL renderer; there's really no point in having those details available in the generic API — especially as the Cairo fallback renderer cannot really set up a complex modelview or a projection matrix.
2016-08-10 16:50:03 +00:00
gsk_gl_renderer_add_render_item (GskGLRenderer *self,
const graphene_matrix_t *projection,
gsk: gsk_render_node_set_transform() => GskTransformNode Instead of having a setter for the transform, have a GskTransformNode. Most of the oprations that GTK does do not require a transform, so it doesn't make sense to have it as a primary attribute. Also, changing the transform requires updating the uniforms of the GL renderer, so we're happy if we can avoid that.
2016-12-12 23:11:06 +00:00
const graphene_matrix_t *modelview,
gsk: Drop modelview/projection from GskRenderer API The details of the modelview and projection matrices are only useful for the GL renderer; there's really no point in having those details available in the generic API — especially as the Cairo fallback renderer cannot really set up a complex modelview or a projection matrix.
2016-08-10 16:50:03 +00:00
GArray *render_items,
GskRenderNode *node,
RenderItem *parent)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
graphene_rect_t viewport;
RenderItem item;
gsk: Use the right pointer to the parent RenderItem We copy the local RenderItem into the render items array, so we need to use the copy in the array in order to get the correct reference.
2016-07-06 16:10:12 +00:00
RenderItem *ritem = NULL;
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
int program_id;
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
int scale_factor;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
memset (&item, 0, sizeof (RenderItem));
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk_renderer_get_viewport (GSK_RENDERER (self), &viewport);
gsk: Remove gsk_render_node_get_scale_factor() Scale factors belong to the renderers, not the nodes. The nodes should just use whatever scale factor the renderer tells them to when rendering.
2016-11-01 03:58:29 +00:00
scale_factor = gsk_renderer_get_scale_factor (GSK_RENDERER (self));
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
if (scale_factor < 1)
scale_factor = 1;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
item.node = node;
item.name = node->name != NULL ? node->name : "unnamed";
/* The texture size */
gsk: Add bounds member to RenderNode Instead of constantly recalculating this (especially recursively for parents!) we do it only on construction, because everything is immutable anyway. Also, most nodes had a bounds already and can use the new parent member instead. We also do direct access to the node bounds rather than calling gsk_render_node_get_bounds in various places, which means we do less copying.
2016-12-21 10:21:38 +00:00
item.size.width = node->bounds.size.width * scale_factor;
item.size.height = node->bounds.size.height * scale_factor;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
/* Each render item is an axis-aligned bounding box that we
* transform using the given transformation matrix
*/
gsk: Add bounds member to RenderNode Instead of constantly recalculating this (especially recursively for parents!) we do it only on construction, because everything is immutable anyway. Also, most nodes had a bounds already and can use the new parent member instead. We also do direct access to the node bounds rather than calling gsk_render_node_get_bounds in various places, which means we do less copying.
2016-12-21 10:21:38 +00:00
item.min.x = node->bounds.origin.x;
item.min.y = node->bounds.origin.y;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
item.min.z = 0.f;
gsk: Add bounds member to RenderNode Instead of constantly recalculating this (especially recursively for parents!) we do it only on construction, because everything is immutable anyway. Also, most nodes had a bounds already and can use the new parent member instead. We also do direct access to the node bounds rather than calling gsk_render_node_get_bounds in various places, which means we do less copying.
2016-12-21 10:21:38 +00:00
item.max.x = item.min.x + node->bounds.size.width;
item.max.y = item.min.y + node->bounds.size.height;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
item.max.z = 0.f;
/* The location of the item, in normalized world coordinates */
gsk: gsk_render_node_set_transform() => GskTransformNode Instead of having a setter for the transform, have a GskTransformNode. Most of the oprations that GTK does do not require a transform, so it doesn't make sense to have it as a primary attribute. Also, changing the transform requires updating the uniforms of the GL renderer, so we're happy if we can avoid that.
2016-12-12 23:11:06 +00:00
graphene_matrix_multiply (modelview, &self->mvp, &item.mvp);
item.z = project_item (projection, modelview);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Replace gsk_render_node_set_opacity() ... with gsk_opacity_node_new(). Also implement support for opacity in gtk_widget_snapshot() using this new node.
2016-12-13 04:49:57 +00:00
item.opacity = 1.0;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Add blend nodes Implement blend mode support in GTK background compositing with it.
2016-12-15 03:24:37 +00:00
item.blend_mode = GSK_BLEND_MODE_DEFAULT;
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
/* Back-pointer to the parent node */
if (parent != NULL)
item.parent_data = &(parent->render_data);
else
item.parent_data = NULL;
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
gsk: Add 'blit' program For the root node we do not need to use blending, as it does not have any backdrop to blend into. We can use a simpler 'blit' program that only takes the content of the source and fills the texture quad with it.
2016-07-04 12:55:00 +00:00
/* Select the program to use */
if (parent != NULL)
program_id = self->blend_program_id;
else
program_id = self->blit_program_id;
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
item.render_data.program_id = program_id;
/* Retrieve all the uniforms and attributes */
gsk: Rename uniforms and attributes in shaders Use appropriate names, and annotate the names with the types — 'u' for uniforms, 'a' for attributes. The common preambles for shaders are split from the bodies, so we need some way to distinguish the uniforms and the attributes just from their name.
2016-07-21 16:17:49 +00:00
item.render_data.source_location =
gsk_shader_builder_get_uniform_location (self->shader_builder, program_id, self->uniforms[SOURCE]);
item.render_data.mask_location =
gsk_shader_builder_get_uniform_location (self->shader_builder, program_id, self->uniforms[MASK]);
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
item.render_data.mvp_location =
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
gsk_shader_builder_get_uniform_location (self->shader_builder, program_id, self->uniforms[MVP]);
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
item.render_data.alpha_location =
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
gsk_shader_builder_get_uniform_location (self->shader_builder, program_id, self->uniforms[ALPHA]);
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
item.render_data.blendMode_location =
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
gsk_shader_builder_get_uniform_location (self->shader_builder, program_id, self->uniforms[BLEND_MODE]);
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
item.render_data.position_location =
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
gsk_shader_builder_get_attribute_location (self->shader_builder, program_id, self->attributes[POSITION]);
gsk: Don't store the uniform and attribute location twice We should keep the ShaderBuilder around and use it to query the various uniform and attribute locations when needed, instead of storing those offsets into the Renderer instance, and copying them. This allows a bit more flexibility, once we have more than one program built into the renderer.
2016-07-03 21:54:30 +00:00
item.render_data.uv_location =
gsk: Consolidate program creation and storage We should use ShaderBuilder to create and store programs for the GL renderer. This allows us to simplify the creation of programs (by moving the compilation phase into the ShaderBuilder::create_program() method), and move towards the ability to create multiple programs and just keep a reference to the program id.
2016-07-04 12:46:22 +00:00
gsk_shader_builder_get_attribute_location (self->shader_builder, program_id, self->attributes[UV]);
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
if (render_node_needs_render_target (node))
{
item.render_data.render_target_id =
gsktexture: Allow attaching render data to textures This allows renderers (or anyone really) to attach "render data" to textures. Only the first render data sticks. You can gsk_texture_set_render_data() with the key you will use to look the data up again, and if no data has been set yet, yours will be set. You can retrieve this data via gsk_texture_get_render_data() later on. If your data has been cleared, NULL will be returned. When gsk_texture_clear_render_data() is called (which the texture will call when it is finalized), your destory notify will be called and you have to release your render data. The GL driver uses this to attach texture ids to GskTextures.
2016-11-16 04:37:20 +00:00
gsk_gl_driver_create_texture (self->gl_driver, item.size.width, item.size.height);
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
gsk_gl_driver_init_texture_empty (self->gl_driver, item.render_data.render_target_id);
gsk_gl_driver_create_render_target (self->gl_driver, item.render_data.render_target_id, TRUE, TRUE);
gsK: Move children handling to GskContainerNode
2016-12-12 18:30:41 +00:00
item.children = g_array_new (FALSE, FALSE, sizeof (RenderItem));
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
}
else
{
gdk: Redo GL drawing Reenable GL drawing, but do it without Cairo. Now, the context passed to gdk_window_begin_draw_frame() decides how drawing is going to happen. If it is NULL, Cairo is used like before. If a context is passed, Cairo may not be used for drawing and gdk_drawing_context_get_cairo_context() is going to return NULL. Instead, the GL renderer must draw to the GL backbuffer and end_draw_frame() is then swapping that to the front. The GskGLRenderer has lost the texture it used to render to and adapted to render directly to the backbuffer instead. The only thing missing is for GtkGLArea to gain back a performant way to render. But it didn't have one since the introduction of GSK, this patchset doesn't change anything about it. The new rendering avoids two indirections (the GSK renderer's texture and the GDK double buffering surface). It improves icon count in the fishbowl demo by 30%.
2016-11-23 04:54:50 +00:00
item.render_data.render_target_id = 0;
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
item.children = NULL;
}
gsk: Remove gsk_render_node_is_surface/texture() Use gsk_render_node_get_node_type() instead.
2016-12-11 01:33:58 +00:00
switch (gsk_render_node_get_node_type (node))
gsk: Allow adding a GL texture as a node content If we already have a GL texture we definitely don't want to use gdk_cairo_draw_from_gl() to draw on a Cairo context if we're going to take the Cairo surface to which we draw and put it into an OpenGL texture.
2016-08-12 15:44:29 +00:00
{
gsk: Remove gsk_render_node_is_surface/texture() Use gsk_render_node_get_node_type() instead.
2016-12-11 01:33:58 +00:00
case GSK_TEXTURE_NODE:
{
GskTexture *texture = gsk_texture_node_get_texture (node);
int gl_min_filter = GL_NEAREST, gl_mag_filter = GL_NEAREST;
get_gl_scaling_filters (node, &gl_min_filter, &gl_mag_filter);
item.render_data.texture_id = gsk_gl_driver_get_texture_for_texture (self->gl_driver,
texture,
gl_min_filter,
gl_mag_filter);
}
break;
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
gsk: Remove gsk_render_node_is_surface/texture() Use gsk_render_node_get_node_type() instead.
2016-12-11 01:33:58 +00:00
case GSK_CAIRO_NODE:
{
cairo_surface_t *surface = gsk_cairo_node_get_surface (node);
int gl_min_filter = GL_NEAREST, gl_mag_filter = GL_NEAREST;
gsk: Check for NULL in calls to gsk_cairo_node_get_surface() That function does actually sometimes return NULL and is documented to do so, so handle that case in the renderers (by omitting the node).
2016-12-15 09:08:46 +00:00
if (surface == NULL)
return;
gsk: Remove gsk_render_node_is_surface/texture() Use gsk_render_node_get_node_type() instead.
2016-12-11 01:33:58 +00:00
get_gl_scaling_filters (node, &gl_min_filter, &gl_mag_filter);
/* Upload the Cairo surface to a GL texture */
item.render_data.texture_id = gsk_gl_driver_create_texture (self->gl_driver,
item.size.width,
item.size.height);
gsk_gl_driver_bind_source_texture (self->gl_driver, item.render_data.texture_id);
gsk_gl_driver_init_texture_with_surface (self->gl_driver,
item.render_data.texture_id,
surface,
gl_min_filter,
gl_mag_filter);
}
break;
gsk: Rework GskTexture We do no longer bind textures to a renderer, instead they are a way for applications to provide texture data. For now, that's it. We've reverted to uploading it from scratch every frame.
2016-11-16 03:14:32 +00:00
gsK: Move children handling to GskContainerNode
2016-12-12 18:30:41 +00:00
case GSK_CONTAINER_NODE:
{
guint i;
for (i = 0; i < gsk_container_node_get_n_children (node); i++)
{
GskRenderNode *child = gsk_container_node_get_child (node, i);
gsk: gsk_render_node_set_transform() => GskTransformNode Instead of having a setter for the transform, have a GskTransformNode. Most of the oprations that GTK does do not require a transform, so it doesn't make sense to have it as a primary attribute. Also, changing the transform requires updating the uniforms of the GL renderer, so we're happy if we can avoid that.
2016-12-12 23:11:06 +00:00
gsk_gl_renderer_add_render_item (self, projection, modelview, render_items, child, ritem);
gsK: Move children handling to GskContainerNode
2016-12-12 18:30:41 +00:00
}
}
return;
gsk: gsk_render_node_set_transform() => GskTransformNode Instead of having a setter for the transform, have a GskTransformNode. Most of the oprations that GTK does do not require a transform, so it doesn't make sense to have it as a primary attribute. Also, changing the transform requires updating the uniforms of the GL renderer, so we're happy if we can avoid that.
2016-12-12 23:11:06 +00:00
case GSK_TRANSFORM_NODE:
{
graphene_matrix_t transform, transformed_mv;
gsk_transform_node_get_transform (node, &transform);
graphene_matrix_multiply (&transform, modelview, &transformed_mv);
gsk_gl_renderer_add_render_item (self,
projection, &transformed_mv,
render_items,
gsk_transform_node_get_child (node),
ritem);
}
return;
gsK: Move children handling to GskContainerNode
2016-12-12 18:30:41 +00:00
case GSK_NOT_A_RENDER_NODE:
gsk: Add fallback code to renderers This code makes renderers fall back to Cairo rendering if they don't know how to handle a render node's type. This allows adding new render nodes with impunity.
2016-12-13 03:20:04 +00:00
g_assert_not_reached ();
gsK: Move children handling to GskContainerNode
2016-12-12 18:30:41 +00:00
return;
gsk: Add fallback code to renderers This code makes renderers fall back to Cairo rendering if they don't know how to handle a render node's type. This allows adding new render nodes with impunity.
2016-12-13 03:20:04 +00:00
default:
{
cairo_surface_t *surface;
cairo_t *cr;
surface = cairo_image_surface_create (CAIRO_FORMAT_ARGB32,
gsk: Add bounds member to RenderNode Instead of constantly recalculating this (especially recursively for parents!) we do it only on construction, because everything is immutable anyway. Also, most nodes had a bounds already and can use the new parent member instead. We also do direct access to the node bounds rather than calling gsk_render_node_get_bounds in various places, which means we do less copying.
2016-12-21 10:21:38 +00:00
ceil (node->bounds.size.width),
ceil (node->bounds.size.height));
gsk: Add fallback code to renderers This code makes renderers fall back to Cairo rendering if they don't know how to handle a render node's type. This allows adding new render nodes with impunity.
2016-12-13 03:20:04 +00:00
cr = cairo_create (surface);
gsk: Add bounds member to RenderNode Instead of constantly recalculating this (especially recursively for parents!) we do it only on construction, because everything is immutable anyway. Also, most nodes had a bounds already and can use the new parent member instead. We also do direct access to the node bounds rather than calling gsk_render_node_get_bounds in various places, which means we do less copying.
2016-12-21 10:21:38 +00:00
cairo_translate (cr, -node->bounds.origin.x, -node->bounds.origin.y);
gsk: Add fallback code to renderers This code makes renderers fall back to Cairo rendering if they don't know how to handle a render node's type. This allows adding new render nodes with impunity.
2016-12-13 03:20:04 +00:00
gsk_render_node_draw (node, cr);
cairo_destroy (cr);
/* Upload the Cairo surface to a GL texture */
item.render_data.texture_id = gsk_gl_driver_create_texture (self->gl_driver,
item.size.width,
item.size.height);
gsk_gl_driver_bind_source_texture (self->gl_driver, item.render_data.texture_id);
gsk_gl_driver_init_texture_with_surface (self->gl_driver,
item.render_data.texture_id,
surface,
GL_NEAREST, GL_NEAREST);
cairo_surface_destroy (surface);
}
break;
gsk: Allow adding a GL texture as a node content If we already have a GL texture we definitely don't want to use gdk_cairo_draw_from_gl() to draw on a Cairo context if we're going to take the Cairo surface to which we draw and put it into an OpenGL texture.
2016-08-12 15:44:29 +00:00
}
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
/* Create the vertex buffers holding the geometry of the quad */
{
GskQuadVertex vertex_data[N_VERTICES] = {
{ { item.min.x, item.min.y }, { 0, 0 }, },
{ { item.min.x, item.max.y }, { 0, 1 }, },
{ { item.max.x, item.min.y }, { 1, 0 }, },
{ { item.max.x, item.max.y }, { 1, 1 }, },
{ { item.min.x, item.max.y }, { 0, 1 }, },
{ { item.max.x, item.min.y }, { 1, 0 }, },
};
item.render_data.vao_id =
gsk_gl_driver_create_vao_for_quad (self->gl_driver,
item.render_data.position_location,
item.render_data.uv_location,
gsk: Pass the appropriate value for the n_quads argument Instead of passing the size of the buffer, we should pass the number of quads; we know what the size of a single quad structure is, so we can do the multiplication internally when creating the VAO. This allows us to print the quads for debugging purposes.
2016-08-04 18:14:51 +00:00
N_VERTICES,
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
vertex_data);
}
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Remove GskRenderNode::parent ... and all related APIs.
2016-12-12 17:54:49 +00:00
GSK_NOTE (OPENGL, g_print ("Adding node <%s>[%p] to render items\n",
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
node->name != NULL ? node->name : "unnamed",
node));
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
g_array_append_val (render_items, item);
gsk: Ensure that non-drawing nodes are supported Non-drawing nodes should skip the texturing phase.
2016-08-09 15:30:13 +00:00
ritem = &g_array_index (render_items, RenderItem, render_items->len - 1);
gsk: Add redirection to FBOs for opacity groups If a node is non-opaque and has a non-zero opacity we need to paint its contents and children first to an off screen buffer, and then render the resulting texture at the desired opacity — otherwise the opacities will combine and result in the wrong rendering.
2016-07-25 16:15:05 +00:00
if (item.children != NULL)
render_items = item.children;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
static gboolean
gsk: Drop modelview/projection from GskRenderer API The details of the modelview and projection matrices are only useful for the GL renderer; there's really no point in having those details available in the generic API — especially as the Cairo fallback renderer cannot really set up a complex modelview or a projection matrix.
2016-08-10 16:50:03 +00:00
gsk_gl_renderer_validate_tree (GskGLRenderer *self,
GskRenderNode *root,
const graphene_matrix_t *projection)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gsk: Remove world matrix support Use the real transform and compute it manually.
2016-12-12 15:52:55 +00:00
graphene_matrix_t identity;
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
if (self->gl_context == NULL)
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
{
GSK_NOTE (OPENGL, g_print ("No valid GL context associated to the renderer"));
return FALSE;
}
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Remove world matrix support Use the real transform and compute it manually.
2016-12-12 15:52:55 +00:00
graphene_matrix_init_identity (&identity);
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
gdk_gl_context_make_current (self->gl_context);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Remove gsk_render_node_get_size() In the brave new world of refactored render nodes, this function doesn't really make any sense anymore. We could turn it into a vfunc, but I don't think it's useful. Especially because even in the brave old world, this function was causing a vastl overallocation of nodes when the GL renderer needed render targets.
2016-12-11 10:55:10 +00:00
self->render_items = g_array_new (FALSE, FALSE, sizeof (RenderItem));
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
gsk_gl_driver_begin_frame (self->gl_driver);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
GSK_NOTE (OPENGL, g_print ("RenderNode -> RenderItem\n"));
gsk: Remove world matrix support Use the real transform and compute it manually.
2016-12-12 15:52:55 +00:00
gsk_gl_renderer_add_render_item (self, projection, &identity, self->render_items, root, NULL);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Remove gsk_render_node_get_size() In the brave new world of refactored render nodes, this function doesn't really make any sense anymore. We could turn it into a vfunc, but I don't think it's useful. Especially because even in the brave old world, this function was causing a vastl overallocation of nodes when the GL renderer needed render targets.
2016-12-11 10:55:10 +00:00
GSK_NOTE (OPENGL, g_print ("Total render items: %d\n",
self->render_items->len));
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
gsk_gl_driver_end_frame (self->gl_driver);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
return TRUE;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
gsk: Flush the GL render items cache Whenever the render tree changes we want to drop the RenderItem arrays, as each item contains a pointer to the GskRenderNode which becomes dangling once the root node changed.
2016-04-26 13:23:12 +00:00
static void
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk_gl_renderer_clear_tree (GskGLRenderer *self)
gsk: Flush the GL render items cache Whenever the render tree changes we want to drop the RenderItem arrays, as each item contains a pointer to the GskRenderNode which becomes dangling once the root node changed.
2016-04-26 13:23:12 +00:00
{
gsk: Reuse VAOs with identical buffers Just like we reuse texture ids with the same size we can, at the expense of a little memory, reuse vertex buffers if they reference the same attributes and contain the same data. Each VAO is marked as free at the end of the frame, and if it's not reused in the following frame, it gets dropped.
2016-08-09 10:24:05 +00:00
int removed_textures, removed_vaos;
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
if (self->gl_context == NULL)
gsk: Flush the GL render items cache Whenever the render tree changes we want to drop the RenderItem arrays, as each item contains a pointer to the GskRenderNode which becomes dangling once the root node changed.
2016-04-26 13:23:12 +00:00
return;
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
gdk_gl_context_make_current (self->gl_context);
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
gsk: Drop opaque/transparent item split We're not going to use separate rendering lists soon, and the way we render items is less similar to a gaming engine and more similar to a simpler compositor. This means we don't need to perform a two pass rendering — opaque items first, transparent items later.
2016-07-21 16:19:53 +00:00
g_clear_pointer (&self->render_items, g_array_unref);
gsk: Recycle textures across frames We keep the textures used inside a frame around until the end of the following frame; whenever we need a texture with the same size, and it's not marked in use, then we just reuse the existing texture.
2016-08-04 11:37:54 +00:00
gsk: Reuse VAOs with identical buffers Just like we reuse texture ids with the same size we can, at the expense of a little memory, reuse vertex buffers if they reference the same attributes and contain the same data. Each VAO is marked as free at the end of the frame, and if it's not reused in the following frame, it gets dropped.
2016-08-09 10:24:05 +00:00
removed_textures = gsk_gl_driver_collect_textures (self->gl_driver);
removed_vaos = gsk_gl_driver_collect_vaos (self->gl_driver);
GSK_NOTE (OPENGL, g_print ("Collected: %d textures, %d vaos\n",
removed_textures,
removed_vaos));
gsk: Flush the GL render items cache Whenever the render tree changes we want to drop the RenderItem arrays, as each item contains a pointer to the GskRenderNode which becomes dangling once the root node changed.
2016-04-26 13:23:12 +00:00
}
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
static void
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk_gl_renderer_clear (GskGLRenderer *self)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
GSK_NOTE (OPENGL, g_print ("Clearing viewport\n"));
glClearColor (0, 0, 0, 0);
gsk: Simplify buffer handling in GskGLRenderer We don't have optional stencil and depth buffers, like GtkGLArea: we always create both of them internally.
2016-07-19 13:42:54 +00:00
glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
static void
gsk_gl_renderer_setup_render_mode (GskGLRenderer *self)
{
switch (self->render_mode)
{
case RENDER_FULL:
glDisable (GL_SCISSOR_TEST);
break;
case RENDER_SCISSOR:
{
GdkDrawingContext *context = gsk_renderer_get_drawing_context (GSK_RENDERER (self));
GdkWindow *window = gsk_renderer_get_window (GSK_RENDERER (self));
GdkRectangle extents;
cairo_region_get_extents (gdk_drawing_context_get_clip (context), &extents);
glScissor (extents.x, gdk_window_get_height (window) - extents.height - extents.y, extents.width, extents.height);
glEnable (GL_SCISSOR_TEST);
break;
}
default:
g_assert_not_reached ();
break;
}
}
gsk: Drop modelview/projection from GskRenderer API The details of the modelview and projection matrices are only useful for the GL renderer; there's really no point in having those details available in the generic API — especially as the Cairo fallback renderer cannot really set up a complex modelview or a projection matrix.
2016-08-10 16:50:03 +00:00
#define ORTHO_NEAR_PLANE -10000
#define ORTHO_FAR_PLANE 10000
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
static void
gsk: Make GskRenderer.render() drawing context-agnostic We're going to need to allow rendering on a specific cairo_t in order to implement fallback code paths inside GTK; this means that there will be times when we have a transient GskRenderer instance that does not have a GdkDrawingContext to draw on. Instead of adding a new render() implementation for those cases and then decide which one to use, we can remove the drawing context argument from the virtual function itself, and allow using a NULL GdkDrawingContext when calling gsk_renderer_render(). A later commit will add a generic function to create a transient GskRenderer with a cairo_t attached to it. Renderers inside GSK will have to check whether we have access to a GdkDrawingContext, in which case we're going to use it; or if we have access to a cairo_t and a window.
2016-08-24 15:21:50 +00:00
gsk_gl_renderer_render (GskRenderer *renderer,
GskRenderNode *root)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
GskGLRenderer *self = GSK_GL_RENDERER (renderer);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
graphene_matrix_t modelview, projection;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
graphene_rect_t viewport;
guint i;
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
int scale_factor;
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#ifdef G_ENABLE_DEBUG
GskProfiler *profiler;
gint64 gpu_time, cpu_time;
#endif
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
if (self->gl_context == NULL)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
return;
gsk: Make GskRenderer.render() drawing context-agnostic We're going to need to allow rendering on a specific cairo_t in order to implement fallback code paths inside GTK; this means that there will be times when we have a transient GskRenderer instance that does not have a GdkDrawingContext to draw on. Instead of adding a new render() implementation for those cases and then decide which one to use, we can remove the drawing context argument from the virtual function itself, and allow using a NULL GdkDrawingContext when calling gsk_renderer_render(). A later commit will add a generic function to create a transient GskRenderer with a cairo_t attached to it. Renderers inside GSK will have to check whether we have access to a GdkDrawingContext, in which case we're going to use it; or if we have access to a cairo_t and a window.
2016-08-24 15:21:50 +00:00
#ifdef G_ENABLE_DEBUG
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
profiler = gsk_renderer_get_profiler (renderer);
gsk: Make GskRenderer.render() drawing context-agnostic We're going to need to allow rendering on a specific cairo_t in order to implement fallback code paths inside GTK; this means that there will be times when we have a transient GskRenderer instance that does not have a GdkDrawingContext to draw on. Instead of adding a new render() implementation for those cases and then decide which one to use, we can remove the drawing context argument from the virtual function itself, and allow using a NULL GdkDrawingContext when calling gsk_renderer_render(). A later commit will add a generic function to create a transient GskRenderer with a cairo_t attached to it. Renderers inside GSK will have to check whether we have access to a GdkDrawingContext, in which case we're going to use it; or if we have access to a cairo_t and a window.
2016-08-24 15:21:50 +00:00
#endif
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
gdk_gl_context_make_current (self->gl_context);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk_renderer_get_viewport (renderer, &viewport);
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
scale_factor = gsk_renderer_get_scale_factor (renderer);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
gsk_gl_driver_begin_frame (self->gl_driver);
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
gsk_gl_renderer_create_buffers (self, viewport.size.width, viewport.size.height, scale_factor);
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
gsk_gl_driver_end_frame (self->gl_driver);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Drop modelview/projection from GskRenderer API The details of the modelview and projection matrices are only useful for the GL renderer; there's really no point in having those details available in the generic API — especially as the Cairo fallback renderer cannot really set up a complex modelview or a projection matrix.
2016-08-10 16:50:03 +00:00
/* Set up the modelview and projection matrices to fit our viewport */
graphene_matrix_init_scale (&modelview, scale_factor, scale_factor, 1.0);
graphene_matrix_init_ortho (&projection,
0, viewport.size.width * scale_factor,
viewport.size.height * scale_factor, 0,
ORTHO_NEAR_PLANE,
ORTHO_FAR_PLANE);
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
gsk_gl_renderer_update_frustum (self, &modelview, &projection);
gsk: Drop modelview/projection from GskRenderer API The details of the modelview and projection matrices are only useful for the GL renderer; there's really no point in having those details available in the generic API — especially as the Cairo fallback renderer cannot really set up a complex modelview or a projection matrix.
2016-08-10 16:50:03 +00:00
if (!gsk_gl_renderer_validate_tree (self, root, &projection))
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
goto out;
gsk_gl_driver_begin_frame (self->gl_driver);
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#ifdef G_ENABLE_DEBUG
gsk: Move resource handling inside GskGLDriver We want the GL driver to cache as many resources as possible, so we can always ensure that we're in a consistent state, and we can handle state transitions more appropriately.
2016-07-20 16:55:35 +00:00
gsk_gl_profiler_begin_gpu_region (self->gl_profiler);
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
gsk_profiler_timer_begin (profiler, self->profile_timers.cpu_time);
#endif
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
/* Ensure that the viewport is up to date */
gdk: Redo GL drawing Reenable GL drawing, but do it without Cairo. Now, the context passed to gdk_window_begin_draw_frame() decides how drawing is going to happen. If it is NULL, Cairo is used like before. If a context is passed, Cairo may not be used for drawing and gdk_drawing_context_get_cairo_context() is going to return NULL. Instead, the GL renderer must draw to the GL backbuffer and end_draw_frame() is then swapping that to the front. The GskGLRenderer has lost the texture it used to render to and adapted to render directly to the backbuffer instead. The only thing missing is for GtkGLArea to gain back a performant way to render. But it didn't have one since the introduction of GSK, this patchset doesn't change anything about it. The new rendering avoids two indirections (the GSK renderer's texture and the GDK double buffering surface). It improves icon count in the fishbowl demo by 30%.
2016-11-23 04:54:50 +00:00
if (gsk_gl_driver_bind_render_target (self->gl_driver, 0))
gsk: Take into account the scaling factor We need to apply a scaling factor whenever we deal with user-supplied coordinates, like: - when creating textures - when setting up the viewport - when submitting the scene
2016-07-27 15:48:35 +00:00
gsk_gl_renderer_resize_viewport (self, &viewport, scale_factor);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gdkgl: Add gdk_gl_context_get_damage() This is a way to query the damaged area of the backbuffer. The GL renderer uses this to compute the extents of that damage region (computed via buffer age) and use them to minimize the area to redraw. This changes the semantics of GL rendering to "When calling gdk_window_begin_frame() with a GL context, the area by gdk_gl_context_get_damage() needs to be redrawn and every other pixel of the backbuffer is guaranteed to be correct. After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer must be correct. We can always glXBufferSwap() now because of this.
2016-12-04 15:33:13 +00:00
gsk_gl_renderer_setup_render_mode (self);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk_gl_renderer_clear (self);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Simplify buffer handling in GskGLRenderer We don't have optional stencil and depth buffers, like GtkGLArea: we always create both of them internally.
2016-07-19 13:42:54 +00:00
glEnable (GL_DEPTH_TEST);
glDepthFunc (GL_LEQUAL);
gsk: Enable depth testing Use the appropriate depth testing function for transparent items.
2016-07-08 15:40:42 +00:00
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
glEnable (GL_BLEND);
gsk: Fix the blend mode The default blend mode should be the equivalent of Cairo's OVER operator.
2016-08-09 15:27:18 +00:00
glBlendFunc (GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Drop opaque/transparent item split We're not going to use separate rendering lists soon, and the way we render items is less similar to a gaming engine and more similar to a simpler compositor. This means we don't need to perform a two pass rendering — opaque items first, transparent items later.
2016-07-21 16:19:53 +00:00
GSK_NOTE (OPENGL, g_print ("Rendering %u items\n", self->render_items->len));
for (i = 0; i < self->render_items->len; i++)
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
{
gsk: Drop opaque/transparent item split We're not going to use separate rendering lists soon, and the way we render items is less similar to a gaming engine and more similar to a simpler compositor. This means we don't need to perform a two pass rendering — opaque items first, transparent items later.
2016-07-21 16:19:53 +00:00
RenderItem *item = &g_array_index (self->render_items, RenderItem, i);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
gsk: Add GskGLDriver We can move the caching and management of textures, VAOs, and state of the GL machinery into a single object, GskGLDriver.
2016-07-08 15:21:13 +00:00
render_item (self, item);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
/* Draw the output of the GL rendering to the window */
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
gsk_gl_driver_end_frame (self->gl_driver);
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#ifdef G_ENABLE_DEBUG
gsk_profiler_counter_inc (profiler, self->profile_counters.frames);
cpu_time = gsk_profiler_timer_end (profiler, self->profile_timers.cpu_time);
gsk_profiler_timer_set (profiler, self->profile_timers.cpu_time, cpu_time);
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
gpu_time = gsk_gl_profiler_end_gpu_region (self->gl_profiler);
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
gsk_profiler_timer_set (profiler, self->profile_timers.gpu_time, gpu_time);
gsk_profiler_push_samples (profiler);
#endif
gsk: Add GL profiler We can use the GL_ARB_timer_query extension (available since OpenGL 3.2, and part of the OpenGL specification since version 3.3) to query the time elapsed when drawing each frame. This allows us to gather timing information on our use of the GPU.
2016-07-12 13:50:48 +00:00
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
out:
gsk: Bind GL context to the GL profiler Similarly to how we bind it to the GL driver object used by the GSK GL renderer.
2016-07-27 10:34:20 +00:00
gdk_gl_context_make_current (self->gl_context);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk_gl_renderer_clear_tree (self);
gsk: Simplify buffer handling in GskGLRenderer We don't have optional stencil and depth buffers, like GtkGLArea: we always create both of them internally.
2016-07-19 13:42:54 +00:00
gsk_gl_renderer_destroy_buffers (self);
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
static void
gsk_gl_renderer_class_init (GskGLRendererClass *klass)
{
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
GskRendererClass *renderer_class = GSK_RENDERER_CLASS (klass);
gobject_class->dispose = gsk_gl_renderer_dispose;
renderer_class->realize = gsk_gl_renderer_realize;
renderer_class->unrealize = gsk_gl_renderer_unrealize;
glrenderer: Always redraw the whole screen
2016-11-27 15:37:31 +00:00
renderer_class->begin_draw_frame = gsk_gl_renderer_begin_draw_frame;
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
renderer_class->render = gsk_gl_renderer_render;
}
static void
gsk_gl_renderer_init (GskGLRenderer *self)
{
gsk_ensure_resources ();
graphene_matrix_init_identity (&self->mvp);
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#ifdef G_ENABLE_DEBUG
{
GskProfiler *profiler = gsk_renderer_get_profiler (GSK_RENDERER (self));
self->profile_counters.frames = gsk_profiler_add_counter (profiler, "frames", "Frames", FALSE);
self->profile_counters.draw_calls = gsk_profiler_add_counter (profiler, "draws", "glDrawArrays", TRUE);
self->profile_timers.cpu_time = gsk_profiler_add_timer (profiler, "cpu-time", "CPU time", FALSE, TRUE);
self->profile_timers.gpu_time = gsk_profiler_add_timer (profiler, "gpu-time", "GPU time", FALSE, TRUE);
}
#endif
Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
}
Reference in New Issue Copy Permalink