AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-11-14 04:31:09 +00:00
Code Issues Projects Releases Wiki Activity
c0db4091cf
gtk/gsk/gskdebug.c

62 lines
1.4 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
#include "gskdebugprivate.h"
#ifdef G_ENABLE_DEBUG
static const GDebugKey gsk_debug_keys[] = {
{ "renderer", GSK_DEBUG_RENDERER },
{ "cairo", GSK_DEBUG_CAIRO },
{ "opengl", GSK_DEBUG_OPENGL },
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
{ "shaders", GSK_DEBUG_SHADERS },
gsk: Add a vulkan debug category
2016-11-30 01:07:57 +00:00
{ "surface", GSK_DEBUG_SURFACE },
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
{ "vulkan", GSK_DEBUG_VULKAN },
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
{ "fallback", GSK_DEBUG_FALLBACK },
gsk: Reorganize env vars Get rid of GSK_RENDERING_MODE and add the flags to GSK_DEBUG, following the same pattern we use in gdk now.
2018-01-14 20:11:33 +00:00
{ "glyphcache", GSK_DEBUG_GLYPH_CACHE },
{ "geometry", GSK_DEBUG_GEOMETRY },
{ "full-redraw", GSK_DEBUG_FULL_REDRAW},
{ "sync", GSK_DEBUG_SYNC },
{ "vulkan-staging-image", GSK_DEBUG_VULKAN_STAGING_IMAGE },
{ "vulkan-staging-buffer", GSK_DEBUG_VULKAN_STAGING_BUFFER }
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
gsk: make logging per-renderer Add a setter for per-renderer debug flags, and use them where possible. Some places don't have easy access to a renderer, so this is not complete. Also, use g_message instead of g_print throughout.
2018-01-14 14:52:52 +00:00
static guint gsk_debug_flags;
static void
init_debug_flags (void)
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
{
#ifdef G_ENABLE_DEBUG
static volatile gsize gsk_debug_flags__set;
if (g_once_init_enter (&gsk_debug_flags__set))
{
const char *env = g_getenv ("GSK_DEBUG");
gsk_debug_flags = g_parse_debug_string (env,
(GDebugKey *) gsk_debug_keys,
G_N_ELEMENTS (gsk_debug_keys));
g_once_init_leave (&gsk_debug_flags__set, TRUE);
}
gsk: make logging per-renderer Add a setter for per-renderer debug flags, and use them where possible. Some places don't have easy access to a renderer, so this is not complete. Also, use g_message instead of g_print throughout.
2018-01-14 14:52:52 +00:00
#endif
}
gboolean
gsk_check_debug_flags (GskDebugFlags flags)
{
init_debug_flags ();
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
return (gsk_debug_flags & flags) != 0;
gsk: make logging per-renderer Add a setter for per-renderer debug flags, and use them where possible. Some places don't have easy access to a renderer, so this is not complete. Also, use g_message instead of g_print throughout.
2018-01-14 14:52:52 +00:00
}
GskDebugFlags
gsk_get_debug_flags (void)
{
init_debug_flags ();
return gsk_debug_flags;
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 a setter for debug flags We need to set the global flags, since these are picked up initially by new renderers.
2018-01-14 21:06:25 +00:00
void
gsk_set_debug_flags (GskDebugFlags flags)
{
init_debug_flags ();
gsk_debug_flags = flags;
}
Reference in New Issue Copy Permalink