AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
04f6b26205
gtk2/gsk/gskdebugprivate.h

64 lines
1.9 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: Add debug category for fallbacks ... and use it for the cases in Vulkan where we fall back to Cairo.
2016-12-23 23:52:07 +00:00
GSK_DEBUG_VULKAN = 1 << 7,
Add some debug output for the glyph cache Print out some statistics and dump the glyph caches to a png, for now.
2017-09-20 03:59:44 +00:00
GSK_DEBUG_FALLBACK = 1 << 8,
GSK_DEBUG_GLYPH_CACHE = 1 << 9
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;
Record node names for debug output This is useful for GSK_NOTE output as well.
2017-09-03 15:29:29 +00:00
#define GSK_DEBUG_ANY ((1 << 9) - 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
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: Add GSK_RENDERING_MODE=full-redraw Forces a full redraw every frame. This is done generically, so it's supported on every renderer. For widget-factory first page (with the spinner spinning and progressbar pulsing), I get these numbers per frame: action clipped full redraw snapshot 0ms 7-10ms cairo rendering 0ms 10-15ms Vulkan rendering 3-5ms 18-20ms Vulkan expected * 0ms 1-2ms GL rendering unsupported 55-62ms * expected means disabling rendering of unsupported render nodes, instead of doing fallback drawing. So it overestimates the performance, because borders and box-shadows are disabled.
2016-12-26 23:33:34 +00:00
GSK_RENDERING_MODE_FULL_REDRAW = 1 << 3,
GSK_RENDERING_MODE_STAGING_IMAGE = 1 << 4,
GSK_RENDERING_MODE_STAGING_BUFFER = 1 << 5
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