AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
50a5deb8e3
gtk2/gsk/gskrendernodeprivate.h

114 lines
3.0 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"
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
#include "gskrenderer.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 <cairo.h>
G_BEGIN_DECLS
#define GSK_RENDER_NODE_CLASS(klass) (G_TYPE_CHECK_CLASS_CAST ((klass), GSK_TYPE_RENDER_NODE, GskRenderNodeClass))
#define GSK_IS_RENDER_NODE_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass), GSK_TYPE_RENDER_NODE))
#define GSK_RENDER_NODE_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj), GSK_TYPE_RENDER_NODE, GskRenderNodeClass))
struct _GskRenderNode
{
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
GTypeInstance parent_instance;
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
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
/* Back pointer to the renderer that created the node */
GskRenderer *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
/* 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: 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 GL surface */
int texture_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
/* 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;
gsk: Rename set_offset() to set_anchor_point() The naming is consistent with other scene graph libraries, as it represents an additional translation transformation applied on top of the provided transformation matrices. We can also simplify the implementation by applying the translation when we compute the world matrix.
2016-08-04 14:20:06 +00:00
graphene_point3d_t anchor_point;
Add an offset to render nodes This will let us account for the difference between clip and allocation.
2016-08-04 05:04:25 +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
/* 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 hidden : 1;
gboolean opaque : 1;
gboolean transform_set : 1;
gboolean needs_world_matrix_update : 1;
};
struct _GskRenderNodeClass
{
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
GTypeClass parent_class;
void (* finalize) (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: 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
GskRenderNode *gsk_render_node_new (GskRenderer *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
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);
cairo_surface_t *gsk_render_node_get_surface (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
int gsk_render_node_get_texture (GskRenderNode *node);
gboolean gsk_render_node_has_surface (GskRenderNode *node);
gboolean gsk_render_node_has_texture (GskRenderNode *node);
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);
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
int gsk_render_node_get_scale_factor (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_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