AuroraMiddleware/gtk
1
0
Fork 1
mirror of https://gitlab.gnome.org/GNOME/gtk.git synced 2024-12-27 06:00:22 +00:00
Code Issues Projects Releases Wiki Activity
9015ed1c43
gtk/gsk/gskdebug.c

58 lines
1.7 KiB
C
Raw Normal View History

gsk: Use the new debug macros
2022-09-23 01:36:50 +00:00
#include "config.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 "gskdebugprivate.h"
Rename gdk-private.h to gdkprivate.h The extra - does not add any value.
2022-09-24 03:23:27 +00:00
#include "gdk/gdkprivate.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
gsk: Better help for GSK_DEBUG Reuse the newly introduced gdk_parse_debug_var for GSK_DEBUG.
2020-06-28 03:09:55 +00:00
static const GdkDebugKey gsk_debug_keys[] = {
{ "renderer", GSK_DEBUG_RENDERER, "General renderer information" },
{ "cairo", GSK_DEBUG_CAIRO, "Cairo renderer information" },
{ "opengl", GSK_DEBUG_OPENGL, "OpenGL renderer information" },
{ "vulkan", GSK_DEBUG_VULKAN, "Vulkan renderer information" },
{ "shaders", GSK_DEBUG_SHADERS, "Information about shaders" },
{ "surface", GSK_DEBUG_SURFACE, "Information about surfaces" },
{ "fallback", GSK_DEBUG_FALLBACK, "Information about fallbacks" },
{ "glyphcache", GSK_DEBUG_GLYPH_CACHE, "Information about glyph caching" },
gsk: Remove an unused debug flag GSK_DEBUG_DIFF was not used anywhere, so remove it.
2020-07-20 01:21:41 +00:00
{ "geometry", GSK_DEBUG_GEOMETRY, "Show borders (when using cairo)" },
gsk: Better help for GSK_DEBUG Reuse the newly introduced gdk_parse_debug_var for GSK_DEBUG.
2020-06-28 03:09:55 +00:00
{ "full-redraw", GSK_DEBUG_FULL_REDRAW, "Force full redraws" },
{ "sync", GSK_DEBUG_SYNC, "Sync after each frame" },
vulkan: Repurpose debug flags for image uploads Now that we don't use the old environment variables anymore to force staging buffer/image uploads, we don't need them. However, we do autodetect the fast path for avoiding a staging buffer now, and we might want to be able to turn that off for testing. So add GSK_DEBUG=staging that does exactly that.
2023-06-14 01:31:11 +00:00
{ "staging", GSK_DEBUG_STAGING, "Use a staging image for texture upload (Vulkan only)" },
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: 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
{
types: fix various use of volatile in type registration The use of volatile was incorrect in GLib and has been that way for a long time. Recently however that has changed, and this makes GTK follow suit to avoid using volatile in the type registration. See also: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719 Combined with the above merge request for GLib, this fixes a large number of compilation warnings when using Clang.
2020-11-19 03:58:09 +00:00
static gsize gsk_debug_flags__set;
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
if (g_once_init_enter (&gsk_debug_flags__set))
{
gsk: Better help for GSK_DEBUG Reuse the newly introduced gdk_parse_debug_var for GSK_DEBUG.
2020-06-28 03:09:55 +00:00
gsk_debug_flags = gdk_parse_debug_var ("GSK_DEBUG",
gsk_debug_keys,
G_N_ELEMENTS (gsk_debug_keys));
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_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
}
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