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

58 lines
2.1 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
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
graphene_rect_t bounds;
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: 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;
gsk: Add custom structs to RenderNode subclasses So now we don't need to keep a texture pointer and a surface pointer and so on in the base struct.
2016-12-11 03:28:21 +00:00
gsize struct_size;
gsk: Introduce GskRenderNodeClass This is modeled after GtkCssValueClass. So far it doesn't do anything.
2016-12-11 02:57:42 +00:00
const char *type_name;
rendernode: Add getters for box-shadow nodes
2017-01-17 23:05:25 +00:00
Make render node getter public Keeping these private does not really buy us anything.
2017-10-20 06:06:20 +00:00
void (* finalize) (GskRenderNode *node);
void (* draw) (GskRenderNode *node,
cairo_t *cr);
rendernode: Add gsk_render_node_diff() ... and gsk_render_node_can_diff(). Those are vfuncs to compute a region containing all the pixels that differ between the two nodes. This is just the plumbing that chains into node classes. No node implements it yet.
2018-03-20 00:37:05 +00:00
gboolean (* can_diff) (GskRenderNode *node1,
GskRenderNode *node2);
void (* diff) (GskRenderNode *node1,
GskRenderNode *node2,
cairo_region_t *region);
Make render node getter public Keeping these private does not really buy us anything.
2017-10-20 06:06:20 +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
Make render node getter public Keeping these private does not really buy us anything.
2017-10-20 06:06:20 +00:00
GskRenderNode * gsk_render_node_new (const GskRenderNodeClass *node_class,
gsize extra_size);
gsk: Add cross-fade node And implement stack crossfades with it.
2016-12-17 06:44:10 +00:00
rendernode: Add gsk_render_node_diff() ... and gsk_render_node_can_diff(). Those are vfuncs to compute a region containing all the pixels that differ between the two nodes. This is just the plumbing that chains into node classes. No node implements it yet.
2018-03-20 00:37:05 +00:00
gboolean gsk_render_node_can_diff (GskRenderNode *node1,
GskRenderNode *node2);
void gsk_render_node_diff (GskRenderNode *node1,
GskRenderNode *node2,
cairo_region_t *region);
void gsk_render_node_diff_impossible (GskRenderNode *node1,
GskRenderNode *node2,
cairo_region_t *region);
Cache glyph textures in render nodes This is a quick implementation that avoids many glyph cache lookups. We keep an array of direct pointers in the text render node, and throw those cached pointers away whenever any atlases have been dropped (since that may invalidate the cached glyphs).
2019-10-15 04:14:43 +00:00
void gsk_text_node_set_render_data (GskRenderNode *node,
gpointer data);
gpointer gsk_text_node_get_render_data (GskRenderNode *node);
rendernode: Add gsk_render_node_diff() ... and gsk_render_node_can_diff(). Those are vfuncs to compute a region containing all the pixels that differ between the two nodes. This is just the plumbing that chains into node classes. No node implements it yet.
2018-03-20 00:37:05 +00:00
gsk: Make gsk_text_node_new_with_bounds private We pulled out the bounds calculation for performance reasons, but the caller can't know how to properly compute them. Inside gtk+, we can do that but it's not good enough for public API.
2018-04-21 09:20:15 +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
G_END_DECLS
#endif /* __GSK_RENDER_NODE_PRIVATE_H__ */
Reference in New Issue Copy Permalink