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
12297fd88a
gtk/gsk/gskdebugprivate.h

61 lines
2.0 KiB
C
Raw Normal View History

Convert headers to #pragma once The conversion was done by guard2one.
2023-03-31 19:11:10 +00:00
#pragma once
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 <glib.h>
Rename gdkdebug.h to gdkdebugprivate.h This is the naming convention for private headers.
2022-09-24 03:11:41 +00:00
#include "gdk/gdkdebugprivate.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
G_BEGIN_DECLS
typedef enum {
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
GSK_DEBUG_RENDERER = 1 << 0,
GSK_DEBUG_CAIRO = 1 << 1,
GSK_DEBUG_OPENGL = 1 << 2,
GSK_DEBUG_SHADERS = 1 << 3,
GSK_DEBUG_SURFACE = 1 << 4,
GSK_DEBUG_VULKAN = 1 << 5,
GSK_DEBUG_FALLBACK = 1 << 6,
GSK_DEBUG_GLYPH_CACHE = 1 << 7,
vulkan: Add infrastructure for printing ops ... and add a GSK_DEBUG=verbose setting making use of it.
2023-07-05 04:32:52 +00:00
GSK_DEBUG_VERBOSE = 1 << 8,
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
/* flags below may affect behavior */
gsk: Implement gsk_render_node_diff() This includes a copy of the diff(1) algorithm used by git diff by Davide Libenzi. It's used for the common case ofcontainer nodes having only very few changes for the few nodes of child widgets that changed (like a button lighting up when hilighted or a spinning spinner).
2018-03-27 22:34:23 +00:00
GSK_DEBUG_GEOMETRY = 1 << 9,
GSK_DEBUG_FULL_REDRAW = 1 << 10,
GSK_DEBUG_SYNC = 1 << 11,
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
GSK_DEBUG_STAGING = 1 << 12
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;
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
#define GSK_DEBUG_ANY ((1 << 13) - 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
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);
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);
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
gboolean gsk_check_debug_flags (GskDebugFlags flags);
#ifdef G_ENABLE_DEBUG
#define GSK_DEBUG_CHECK(type) G_UNLIKELY (gsk_check_debug_flags (GSK_DEBUG_ ## type))
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
#define GSK_RENDERER_DEBUG_CHECK(renderer,type) \
G_UNLIKELY ((gsk_renderer_get_debug_flags (renderer) & GSK_DEBUG_ ## type) != 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
gsk: Introduce new debug macros Introduce GSK_RENDERER_DEBUG() and GSK_DEBUG(), which mirror the new macros in gdk. They use the same helper function gdk_debug_message().
2022-09-23 01:35:24 +00:00
#define GSK_RENDERER_DEBUG(renderer,type,...) \
gtk: Use the new debug macros
2022-09-23 14:11:59 +00:00
G_STMT_START { \
gsk: Introduce new debug macros Introduce GSK_RENDERER_DEBUG() and GSK_DEBUG(), which mirror the new macros in gdk. They use the same helper function gdk_debug_message().
2022-09-23 01:35:24 +00:00
if (GSK_RENDERER_DEBUG_CHECK (renderer,type)) \
gdk_debug_message (__VA_ARGS__); \
gtk: Use the new debug macros
2022-09-23 14:11:59 +00:00
} G_STMT_END
gsk: Introduce new debug macros Introduce GSK_RENDERER_DEBUG() and GSK_DEBUG(), which mirror the new macros in gdk. They use the same helper function gdk_debug_message().
2022-09-23 01:35:24 +00:00
#define GSK_DEBUG(type,...) \
gtk: Use the new debug macros
2022-09-23 14:11:59 +00:00
G_STMT_START { \
gsk: Introduce new debug macros Introduce GSK_RENDERER_DEBUG() and GSK_DEBUG(), which mirror the new macros in gdk. They use the same helper function gdk_debug_message().
2022-09-23 01:35:24 +00:00
if (GSK_DEBUG_CHECK (type)) \
gdk_debug_message (__VA_ARGS__); \
gtk: Use the new debug macros
2022-09-23 14:11:59 +00:00
} G_STMT_END
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
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_DEBUG_CHECK(type) 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
#define GSK_RENDERER_DEBUG_CHECK(renderer,type) 0
gsk: Introduce new debug macros Introduce GSK_RENDERER_DEBUG() and GSK_DEBUG(), which mirror the new macros in gdk. They use the same helper function gdk_debug_message().
2022-09-23 01:35:24 +00:00
#define GSK_RENDERER_DEBUG(display,type,...)
#define GSK_DEBUG(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
#endif
G_END_DECLS
Reference in New Issue Copy Permalink