AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-11-10 10:50:10 +00:00
Code Issues Projects Releases Wiki Activity
be8b9406e5
gtk/gsk/gskrendernodeprivate.h

102 lines
2.5 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
#ifndef __GSK_RENDER_NODE_PRIVATE_H__
#define __GSK_RENDER_NODE_PRIVATE_H__
#include "gskrendernode.h"
#include <cairo.h>
G_BEGIN_DECLS
gsk: Introduce GskRenderNodeClass This is modeled after GtkCssValueClass. So far it doesn't do anything.
2016-12-11 02:57:42 +00:00
typedef struct _GskRenderNodeClass GskRenderNodeClass;
#define GSK_IS_RENDER_NODE_TYPE(node,type) (GSK_IS_RENDER_NODE (node) && (node)->node_class->node_type == (type))
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 _GskRenderNode
{
gsk: Introduce GskRenderNodeClass This is modeled after GtkCssValueClass. So far it doesn't do anything.
2016-12-11 02:57:42 +00:00
const GskRenderNodeClass *node_class;
gsk: Add GskRenderNodeType For now, this is unused.
2016-12-10 20:42:01 +00:00
gsk: Turn GskRenderNode into a pure GTypeInstance Using GObject as the base type for a transient tree may prove to be too intensive, especially when creating a lot of node instances. Since we don't need properties or signals, and we don't need complex destruction semantics, we can use GTypeInstance directly as the base type for GskRenderNode.
2016-06-29 18:05:33 +00:00
volatile int ref_count;
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
/* The graph */
GskRenderNode *parent;
GskRenderNode *first_child;
GskRenderNode *last_child;
GskRenderNode *prev_sibling;
GskRenderNode *next_sibling;
int n_children;
/* Use for debugging */
char *name;
/* Tag updated when adding/removing children */
gint64 age;
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
/* The contents of the node as a Cairo surface */
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
cairo_surface_t *surface;
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
/* The contents of the node as a texture */
GskTexture *texture;
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
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
/* Paint opacity */
double opacity;
gsk: Store blend mode in the render node
2016-07-01 11:12:30 +00:00
/* Blend mode */
GskBlendMode blend_mode;
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
/* Scaling filters */
GskScalingFilter min_filter;
GskScalingFilter 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
/* Clip rectangle */
graphene_rect_t bounds;
/* Transformations relative to the root of the scene */
graphene_matrix_t world_matrix;
/* Transformations applied to the node */
graphene_matrix_t transform;
/* Bit fields; leave at the end */
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
gboolean is_mutable : 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
gboolean opaque : 1;
gboolean transform_set : 1;
gboolean needs_world_matrix_update : 1;
};
gsk: Introduce GskRenderNodeClass This is modeled after GtkCssValueClass. So far it doesn't do anything.
2016-12-11 02:57:42 +00:00
struct _GskRenderNodeClass
{
GskRenderNodeType node_type;
const char *type_name;
gsk: Add GskRenderNodeClass.finalize()
2016-12-11 03:18:25 +00:00
void (* finalize) (GskRenderNode *node);
gsk: Introduce GskRenderNodeClass This is modeled after GtkCssValueClass. So far it doesn't do anything.
2016-12-11 02:57:42 +00:00
};
GskRenderNode *gsk_render_node_new (const GskRenderNodeClass *node_class);
gsk: Tie render nodes to renderers Render nodes need access to rendering information like scaling factors. If we keep render nodes separate from renderers until we submit a nodes tree for rendering we're going to have to duplicate all that information in a way that makes the API more complicated and fuzzier on its semantics. By having GskRenderer create GskRenderNode instances we can tie nodes and renderers together; since higher layers will also have access to the renderer instance, this does not add any burden to callers. Additionally, if memory measurements indicate that we are spending too much time in the allocation of new render nodes, we can now easily implement a free-list or a renderer-specific allocator without breaking the API.
2016-07-27 15:23:44 +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
void gsk_render_node_make_immutable (GskRenderNode *node);
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
void gsk_render_node_get_bounds (GskRenderNode *node,
graphene_rect_t *frame);
void gsk_render_node_get_transform (GskRenderNode *node,
graphene_matrix_t *mv);
double gsk_render_node_get_opacity (GskRenderNode *node);
gsk: Add gsk_cairo_node_new() Split off Cairo drawn content nodes and require you to allocate them using this new function.
2016-12-11 00:23:02 +00:00
cairo_surface_t *gsk_cairo_node_get_surface (GskRenderNode *node);
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 gsk_texture_node_new() Start the transition into the different node types.
2016-12-10 21:52:22 +00:00
GskTexture *gsk_texture_node_get_texture (GskRenderNode *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: Move GskRenderNode getters to internal API GskRenderNode is, at its core, a write-only API; you're supposed to set up the render nodes instead of querying them for state. Querying render nodes is left to the GskRenderer implementation.
2016-08-24 13:07:26 +00:00
GskBlendMode gsk_render_node_get_blend_mode (GskRenderNode *node);
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
GskRenderNode *gsk_render_node_get_toplevel (GskRenderNode *node);
void gsk_render_node_update_world_matrix (GskRenderNode *node,
gboolean force);
void gsk_render_node_get_world_matrix (GskRenderNode *node,
graphene_matrix_t *mv);
gsk: Allow sampling between parent and child nodes
2016-06-30 16:06:31 +00:00
int gsk_render_node_get_size (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
G_END_DECLS
#endif /* __GSK_RENDER_NODE_PRIVATE_H__ */
Reference in New Issue Copy Permalink