AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-12-30 15:31:34 +00:00
Code Issues Projects Releases Wiki Activity
453478719d
gtk/gsk/gskdebugprivate.h

59 lines
1.8 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_DEBUG_PRIVATE_H__
#define __GSK_DEBUG_PRIVATE_H__
#include <glib.h>
G_BEGIN_DECLS
typedef enum {
GSK_DEBUG_RENDER_NODE = 1 << 0,
GSK_DEBUG_RENDERER = 1 << 1,
GSK_DEBUG_CAIRO = 1 << 2,
gsk: Add specific debug type for shaders So that we don't lose GskShaderBuilder debugging messages in the stream of GskGLRenderer ones.
2016-07-08 15:22:33 +00:00
GSK_DEBUG_OPENGL = 1 << 3,
gsk: Add a debug flag for transforms
2016-08-03 01:53:31 +00:00
GSK_DEBUG_SHADERS = 1 << 4,
Some debug help Make the bounds of drawing surfaces created by render nodes visible. Trigger with GSK_DEBUG=surface.
2016-08-06 13:37:47 +00:00
GSK_DEBUG_TRANSFORMS = 1 << 5,
gsk: Add a vulkan debug category
2016-11-30 01:07:57 +00:00
GSK_DEBUG_SURFACE = 1 << 6,
GSK_DEBUG_VULKAN = 1 << 7
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
} GskDebugFlags;
typedef enum {
vulkan: Implement staging-buffer image upload This is not enabled by default. Use GSK_RENDERING_MODE=staging-buffer to use the code.
2016-12-15 23:22:23 +00:00
GSK_RENDERING_MODE_GEOMETRY = 1 << 0,
GSK_RENDERING_MODE_SHADERS = 1 << 1,
GSK_RENDERING_MODE_SYNC = 1 << 2,
GSK_RENDERING_MODE_STAGING_IMAGE = 1 << 3,
GSK_RENDERING_MODE_STAGING_BUFFER = 1 << 4
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
} GskRenderingMode;
gboolean gsk_check_debug_flags (GskDebugFlags flags);
gboolean gsk_check_rendering_flags (GskRenderingMode flags);
#ifdef G_ENABLE_DEBUG
#define GSK_DEBUG_CHECK(type) G_UNLIKELY (gsk_check_debug_flags (GSK_DEBUG_ ## type))
gsk: Add debug macros that trigger on two conditions This will be useful in the following commits.
2016-08-03 01:56:17 +00:00
#define GSK_DEBUG_CHECK2(type1,type2) G_UNLIKELY (gsk_check_debug_flags (GSK_DEBUG_ ## type1 | GSK_DEBUG_ ## type2))
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 GSK_RENDER_MODE_CHECK(type) G_UNLIKELY (gsk_check_rendering_flags (GSK_RENDERING_MODE_ ## type))
#define GSK_NOTE(type,action) G_STMT_START { \
if (GSK_DEBUG_CHECK (type)) { \
action; \
} } G_STMT_END
gsk: Add debug macros that trigger on two conditions This will be useful in the following commits.
2016-08-03 01:56:17 +00:00
#define GSK_NOTE2(type1,type2,action) G_STMT_START { \
if (GSK_DEBUG_CHECK2 (type1, type2)) { \
action; \
} } G_STMT_END
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
#else
#define GSK_RENDER_MODE_CHECK(type) 0
#define GSK_DEBUG_CHECK(type) 0
gsk: Add debug macros that trigger on two conditions This will be useful in the following commits.
2016-08-03 01:56:17 +00:00
#define GSK_DEBUG_CHECK2(type1,type2) 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
#define GSK_NOTE(type,action)
gsk: Add debug macros that trigger on two conditions This will be useful in the following commits.
2016-08-03 01:56:17 +00:00
#define GSK_NOTE2(type1,type2,action)
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
#endif
G_END_DECLS
#endif /* __GSK_DEBUG_PRIVATE_H__ */
Reference in New Issue Copy Permalink