AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
2a0e7f8829
gtk2/gsk/gskrenderer.c

924 lines
25 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
/* GSK - The GTK Scene Kit
*
* Copyright 2016 Endless
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
*/
/**
* SECTION:GskRenderer
Small fixes for the docs Set titles and short descriptions for the sections.
2016-08-07 03:08:04 +00:00
* @Title: GskRenderer
* @Short_description: Renders a scene
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
*
docs: Add more GSK documentation
2016-07-03 23:23:19 +00:00
* #GskRenderer is a class that renders a scene graph defined via a
* tree of #GskRenderNode instances.
*
* Typically you will use a #GskRenderer instance with a #GdkDrawingContext
* associated to a #GdkWindow, and call gsk_renderer_render() with the
* drawing context and the scene to be rendered.
*
* It is necessary to realize a #GskRenderer instance using gsk_renderer_realize()
* before calling gsk_renderer_render(), in order to create the appropriate
* windowing system resources needed to render the scene.
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 "config.h"
#include "gskrendererprivate.h"
gsk: Add the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
#include "gskcairorendererprivate.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"
#include "gskglrendererprivate.h"
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#include "gskprofilerprivate.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 "gskrendernodeprivate.h"
gsk: Add GskTexture
2016-11-07 16:59:38 +00:00
#include "gsktexture.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 "gskenumtypes.h"
#include <graphene-gobject.h>
#include <cairo-gobject.h>
#include <gdk/gdk.h>
#ifdef GDK_WINDOWING_X11
#include <gdk/x11/gdkx.h>
#endif
#ifdef GDK_WINDOWING_WAYLAND
#include <gdk/wayland/gdkwayland.h>
#endif
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
#ifdef GDK_WINDOWING_VULKAN
#include "gskvulkanrendererprivate.h"
#endif
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 struct
{
GObject parent_instance;
graphene_rect_t viewport;
GskScalingFilter min_filter;
GskScalingFilter mag_filter;
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
GdkWindow *window;
GdkDrawingContext *drawing_context;
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
GskRenderNode *root_node;
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
GdkDisplay *display;
gsk: Add the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
cairo_t *cairo_context;
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 GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
GskProfiler *profiler;
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
int scale_factor;
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 is_realized : 1;
} GskRendererPrivate;
G_DEFINE_ABSTRACT_TYPE_WITH_PRIVATE (GskRenderer, gsk_renderer, G_TYPE_OBJECT)
enum {
PROP_VIEWPORT = 1,
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
PROP_SCALE_FACTOR,
PROP_WINDOW,
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
PROP_DISPLAY,
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
PROP_DRAWING_CONTEXT,
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
N_PROPS
};
static GParamSpec *gsk_renderer_properties[N_PROPS];
#define GSK_RENDERER_WARN_NOT_IMPLEMENTED_METHOD(obj,method) \
g_critical ("Renderer of type '%s' does not implement GskRenderer::" # method, G_OBJECT_TYPE_NAME (obj))
static gboolean
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
gsk_renderer_real_realize (GskRenderer *self,
GdkWindow *window,
GError **error)
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_RENDERER_WARN_NOT_IMPLEMENTED_METHOD (self, realize);
return FALSE;
}
static void
gsk_renderer_real_unrealize (GskRenderer *self)
{
GSK_RENDERER_WARN_NOT_IMPLEMENTED_METHOD (self, unrealize);
}
gskrenderer: Add gsk_renderer_begin_draw_frame() This way, we can hijack the begin/end draw process and do out own processing before passing it on to GDK.
2016-11-27 15:21:02 +00:00
static GdkDrawingContext *
gsk_renderer_real_begin_draw_frame (GskRenderer *self,
const cairo_region_t *region)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (self);
return gdk_window_begin_draw_frame (priv->window,
gdk: Make gdk_window_begin_draw_frame() take a draw context ... instead of a gl context. This requires some refactoring in the way we mark the shared context as drawing: We now call begin_frame/end_frame() on it and ignore the call on the main context. Unfortunately we need to do this check in all vfuncs, which sucks. But I haven't found a better way.
2016-12-01 00:38:20 +00:00
NULL,
gskrenderer: Add gsk_renderer_begin_draw_frame() This way, we can hijack the begin/end draw process and do out own processing before passing it on to GDK.
2016-11-27 15:21:02 +00:00
region);
}
static void
gsk_renderer_real_end_draw_frame (GskRenderer *self,
GdkDrawingContext *context)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (self);
gdk_window_end_draw_frame (priv->window,
context);
}
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
static void
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk_renderer_real_render (GskRenderer *self,
gsk: Make GskRenderer.render() drawing context-agnostic We're going to need to allow rendering on a specific cairo_t in order to implement fallback code paths inside GTK; this means that there will be times when we have a transient GskRenderer instance that does not have a GdkDrawingContext to draw on. Instead of adding a new render() implementation for those cases and then decide which one to use, we can remove the drawing context argument from the virtual function itself, and allow using a NULL GdkDrawingContext when calling gsk_renderer_render(). A later commit will add a generic function to create a transient GskRenderer with a cairo_t attached to it. Renderers inside GSK will have to check whether we have access to a GdkDrawingContext, in which case we're going to use it; or if we have access to a cairo_t and a window.
2016-08-24 15:21:50 +00:00
GskRenderNode *root)
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_RENDERER_WARN_NOT_IMPLEMENTED_METHOD (self, render);
}
gsk: Add internal Renderer.create_cairo_surface() We need an overridable entry point for GskRenderer to create Cairo surfaces. Implementations of GskRenderer can override create_cairo_surface() to create efficient surfaces, possibly with zero copies involved, depending on the GDK backend.
2016-10-31 16:26:50 +00:00
static cairo_surface_t *
gsk_renderer_real_create_cairo_surface (GskRenderer *self,
cairo_format_t format,
int width,
int height)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (self);
int scale_factor = priv->scale_factor > 0 ? priv->scale_factor : 1;
int real_width = width * scale_factor;
int real_height = height * scale_factor;
cairo_surface_t *res = cairo_image_surface_create (format, real_width, real_height);
cairo_surface_set_device_scale (res, scale_factor, scale_factor);
return res;
}
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
static void
gsk_renderer_dispose (GObject *gobject)
{
GskRenderer *self = GSK_RENDERER (gobject);
GskRendererPrivate *priv = gsk_renderer_get_instance_private (self);
gsk_renderer_unrealize (self);
gsk: Add the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
g_clear_pointer (&priv->cairo_context, cairo_destroy);
gsk: Clear the profiler instance When disposing the GskRenderer.
2016-10-18 15:49:21 +00:00
g_clear_object (&priv->profiler);
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_clear_object (&priv->display);
G_OBJECT_CLASS (gsk_renderer_parent_class)->dispose (gobject);
}
static void
gsk_renderer_set_property (GObject *gobject,
guint prop_id,
const GValue *value,
GParamSpec *pspec)
{
GskRenderer *self = GSK_RENDERER (gobject);
GskRendererPrivate *priv = gsk_renderer_get_instance_private (self);
switch (prop_id)
{
case PROP_VIEWPORT:
gsk_renderer_set_viewport (self, g_value_get_boxed (value));
break;
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
case PROP_SCALE_FACTOR:
gsk_renderer_set_scale_factor (self, g_value_get_int (value));
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
break;
case PROP_DISPLAY:
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
/* Construct-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
priv->display = g_value_dup_object (value);
break;
}
}
static void
gsk_renderer_get_property (GObject *gobject,
guint prop_id,
GValue *value,
GParamSpec *pspec)
{
GskRenderer *self = GSK_RENDERER (gobject);
GskRendererPrivate *priv = gsk_renderer_get_instance_private (self);
switch (prop_id)
{
case PROP_VIEWPORT:
g_value_set_boxed (value, &priv->viewport);
break;
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
case PROP_SCALE_FACTOR:
g_value_set_int (value, priv->scale_factor);
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
break;
case PROP_WINDOW:
g_value_set_object (value, priv->window);
break;
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
case PROP_DRAWING_CONTEXT:
g_value_set_object (value, priv->drawing_context);
break;
case PROP_DISPLAY:
g_value_set_object (value, priv->display);
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
break;
}
}
static void
gsk_renderer_constructed (GObject *gobject)
{
GskRenderer *self = GSK_RENDERER (gobject);
GskRendererPrivate *priv = gsk_renderer_get_instance_private (self);
if (priv->display == NULL)
{
GdkDisplayManager *manager = gdk_display_manager_get ();
priv->display = gdk_display_manager_get_default_display (manager);
g_assert (priv->display != NULL);
}
G_OBJECT_CLASS (gsk_renderer_parent_class)->constructed (gobject);
}
static void
gsk_renderer_class_init (GskRendererClass *klass)
{
GObjectClass *gobject_class = G_OBJECT_CLASS (klass);
klass->realize = gsk_renderer_real_realize;
klass->unrealize = gsk_renderer_real_unrealize;
gskrenderer: Add gsk_renderer_begin_draw_frame() This way, we can hijack the begin/end draw process and do out own processing before passing it on to GDK.
2016-11-27 15:21:02 +00:00
klass->begin_draw_frame = gsk_renderer_real_begin_draw_frame;
klass->end_draw_frame = gsk_renderer_real_end_draw_frame;
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
klass->render = gsk_renderer_real_render;
gsk: Add internal Renderer.create_cairo_surface() We need an overridable entry point for GskRenderer to create Cairo surfaces. Implementations of GskRenderer can override create_cairo_surface() to create efficient surfaces, possibly with zero copies involved, depending on the GDK backend.
2016-10-31 16:26:50 +00:00
klass->create_cairo_surface = gsk_renderer_real_create_cairo_surface;
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
gobject_class->constructed = gsk_renderer_constructed;
gobject_class->set_property = gsk_renderer_set_property;
gobject_class->get_property = gsk_renderer_get_property;
gobject_class->dispose = gsk_renderer_dispose;
/**
* GskRenderer:viewport:
*
* The visible area used by the #GskRenderer to render its contents.
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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_renderer_properties[PROP_VIEWPORT] =
g_param_spec_boxed ("viewport",
"Viewport",
"The visible area used by the renderer",
GRAPHENE_TYPE_RECT,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS |
G_PARAM_EXPLICIT_NOTIFY);
/**
* GskRenderer:display:
*
* The #GdkDisplay used by the #GskRenderer.
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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_renderer_properties[PROP_DISPLAY] =
g_param_spec_object ("display",
"Display",
"The GdkDisplay object used by the renderer",
GDK_TYPE_DISPLAY,
G_PARAM_READWRITE |
G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
gsk_renderer_properties[PROP_WINDOW] =
g_param_spec_object ("window",
"Window",
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
"The window associated to the renderer",
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
GDK_TYPE_WINDOW,
G_PARAM_READWRITE |
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
G_PARAM_CONSTRUCT_ONLY |
G_PARAM_STATIC_STRINGS);
/**
* GskRenderer:scale-factor:
*
* The scale factor used when rendering.
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
*/
gsk_renderer_properties[PROP_SCALE_FACTOR] =
g_param_spec_int ("scale-factor",
"Scale Factor",
"The scaling factor of the renderer",
1, G_MAXINT,
1,
G_PARAM_READWRITE |
G_PARAM_STATIC_STRINGS |
G_PARAM_EXPLICIT_NOTIFY);
/**
* GskRenderer:drawing-context:
*
* The drawing context used when rendering.
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
*/
gsk_renderer_properties[PROP_DRAWING_CONTEXT] =
g_param_spec_object ("drawing-context",
"Drawing Context",
"The drawing context used by the renderer",
GDK_TYPE_DRAWING_CONTEXT,
G_PARAM_READABLE |
G_PARAM_STATIC_STRINGS);
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_object_class_install_properties (gobject_class, N_PROPS, gsk_renderer_properties);
}
static void
gsk_renderer_init (GskRenderer *self)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (self);
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
priv->profiler = gsk_profiler_new ();
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
priv->scale_factor = 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_renderer_set_viewport:
* @renderer: a #GskRenderer
* @viewport: (nullable): the viewport rectangle used by the @renderer
*
* Sets the visible rectangle to be used as the viewport for
* the rendering.
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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
*/
void
gsk_renderer_set_viewport (GskRenderer *renderer,
const graphene_rect_t *viewport)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_if_fail (GSK_IS_RENDERER (renderer));
if (viewport == NULL)
{
graphene_rect_init (&priv->viewport, 0.f, 0.f, 0.f, 0.f);
g_object_notify_by_pspec (G_OBJECT (renderer), gsk_renderer_properties[PROP_VIEWPORT]);
return;
}
if (graphene_rect_equal (viewport, &priv->viewport))
return;
graphene_rect_init_from_rect (&priv->viewport, viewport);
g_object_notify_by_pspec (G_OBJECT (renderer), gsk_renderer_properties[PROP_VIEWPORT]);
}
/**
* gsk_renderer_get_viewport:
* @renderer: a #GskRenderer
* @viewport: (out caller-allocates): return location for the viewport rectangle
*
* Retrieves the viewport of the #GskRenderer.
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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
*/
void
gsk_renderer_get_viewport (GskRenderer *renderer,
graphene_rect_t *viewport)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_if_fail (GSK_IS_RENDERER (renderer));
g_return_if_fail (viewport != NULL);
graphene_rect_init_from_rect (viewport, &priv->viewport);
}
Small documentation additions
2016-08-07 03:19:40 +00:00
/**
* gsk_renderer_set_scale_factor:
* @renderer: a #GskRenderer
* @scale_factor: the new scale factor
*
* Sets the scale factor for the renderer.
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
Small documentation additions
2016-08-07 03:19:40 +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
void
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk_renderer_set_scale_factor (GskRenderer *renderer,
int scale_factor)
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
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_if_fail (GSK_IS_RENDERER (renderer));
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
if (priv->scale_factor != scale_factor)
{
priv->scale_factor = scale_factor;
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
g_object_notify_by_pspec (G_OBJECT (renderer), gsk_renderer_properties[PROP_SCALE_FACTOR]);
}
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
}
Small documentation additions
2016-08-07 03:19:40 +00:00
/**
* gsk_renderer_get_scale_factor:
* @renderer: a #GskRenderer
*
* Gets the scale factor for the @renderer.
*
* Returns: the scale factor
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
Small documentation additions
2016-08-07 03:19:40 +00:00
*/
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
int
gsk_renderer_get_scale_factor (GskRenderer *renderer)
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
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
g_return_val_if_fail (GSK_IS_RENDERER (renderer), 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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
return priv->scale_factor;
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* gsk_renderer_get_window:
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
* @renderer: a #GskRenderer
*
gsk: Change gsk_renderer_realize() Instead of having a gsk_renderer_set_window() call, pass the window to realize(). This way, the realization can fail with the wrong window. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 02:36:33 +00:00
* Retrieves the #GdkWindow set using gsk_renderer_realize(). If the renderer
* has not been realized yet, %NULL will be returned.
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* Returns: (transfer none) (nullable): a #GdkWindow
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: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
GdkWindow *
gsk_renderer_get_window (GskRenderer *renderer)
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
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_val_if_fail (GSK_IS_RENDERER (renderer), NULL);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
return priv->window;
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
/*< private >
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_renderer_get_root_node:
* @renderer: a #GskRenderer
*
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* Retrieves the #GskRenderNode used by @renderer.
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
*
* Returns: (transfer none) (nullable): a #GskRenderNode
*/
GskRenderNode *
gsk_renderer_get_root_node (GskRenderer *renderer)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_val_if_fail (GSK_IS_RENDERER (renderer), NULL);
return priv->root_node;
}
/*< private >
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* gsk_renderer_get_drawing_context:
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
* @renderer: a #GskRenderer
*
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* Retrieves the #GdkDrawingContext used by @renderer.
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* Returns: (transfer none) (nullable): a #GdkDrawingContext
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
GdkDrawingContext *
gsk_renderer_get_drawing_context (GskRenderer *renderer)
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
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
g_return_val_if_fail (GSK_IS_RENDERER (renderer), NULL);
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
return priv->drawing_context;
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* gsk_renderer_get_display:
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
* @renderer: a #GskRenderer
*
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* Retrieves the #GdkDisplay used when creating the #GskRenderer.
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* Returns: (transfer none): a #GdkDisplay
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: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
GdkDisplay *
gsk_renderer_get_display (GskRenderer *renderer)
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
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
g_return_val_if_fail (GSK_IS_RENDERER (renderer), NULL);
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
return priv->display;
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
/*< private >
* gsk_renderer_is_realized:
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
* @renderer: a #GskRenderer
*
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* Checks whether the @renderer is realized or not.
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* Returns: %TRUE if the #GskRenderer was realized, and %FALSE otherwise
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: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gboolean
gsk_renderer_is_realized (GskRenderer *renderer)
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
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
g_return_val_if_fail (GSK_IS_RENDERER (renderer), FALSE);
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
return priv->is_realized;
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_renderer_realize:
* @renderer: a #GskRenderer
gsk: Change gsk_renderer_realize() Instead of having a gsk_renderer_set_window() call, pass the window to realize(). This way, the realization can fail with the wrong window. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 02:36:33 +00:00
* @window: the #GdkWindow renderer will be used on
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
* @error: return location for an error
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
*
* Creates the resources needed by the @renderer to render the scene
* graph.
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
gsk_renderer_realize (GskRenderer *renderer,
GdkWindow *window,
GError **error)
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
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_val_if_fail (GSK_IS_RENDERER (renderer), FALSE);
gsk: Change gsk_renderer_realize() Instead of having a gsk_renderer_set_window() call, pass the window to realize(). This way, the realization can fail with the wrong window. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 02:36:33 +00:00
g_return_val_if_fail (!gsk_renderer_is_realized (renderer), FALSE);
g_return_val_if_fail (GDK_IS_WINDOW (window), FALSE);
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
g_return_val_if_fail (error == NULL || *error == NULL, FALSE);
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: Change gsk_renderer_realize() Instead of having a gsk_renderer_set_window() call, pass the window to realize(). This way, the realization can fail with the wrong window. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 02:36:33 +00:00
priv->window = g_object_ref (window);
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
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
if (!GSK_RENDERER_GET_CLASS (renderer)->realize (renderer, window, error))
gsk: Change gsk_renderer_realize() Instead of having a gsk_renderer_set_window() call, pass the window to realize(). This way, the realization can fail with the wrong window. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 02:36:33 +00:00
{
g_clear_object (&priv->window);
return FALSE;
}
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: Change gsk_renderer_realize() Instead of having a gsk_renderer_set_window() call, pass the window to realize(). This way, the realization can fail with the wrong window. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 02:36:33 +00:00
priv->is_realized = TRUE;
return TRUE;
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_renderer_unrealize:
* @renderer: a #GskRenderer
*
* Releases all the resources created by gsk_renderer_realize().
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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
*/
void
gsk_renderer_unrealize (GskRenderer *renderer)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_if_fail (GSK_IS_RENDERER (renderer));
if (!priv->is_realized)
return;
GSK_RENDERER_GET_CLASS (renderer)->unrealize (renderer);
priv->is_realized = FALSE;
}
/**
* gsk_renderer_render:
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* @renderer: a #GskRenderer
* @root: a #GskRenderNode
gskrenderer: Add gsk_renderer_begin_draw_frame() This way, we can hijack the begin/end draw process and do out own processing before passing it on to GDK.
2016-11-27 15:21:02 +00:00
* @context: The drawing context created via gsk_renderer_begin_draw_frame()
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
*
* Renders the scene graph, described by a tree of #GskRenderNode instances,
* using the given #GdkDrawingContext.
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: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
* The @renderer will acquire a reference on the #GskRenderNode tree while
* the rendering is in progress, and will make the tree immutable.
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: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
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
*/
void
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
gsk_renderer_render (GskRenderer *renderer,
GskRenderNode *root,
GdkDrawingContext *context)
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
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_if_fail (GSK_IS_RENDERER (renderer));
g_return_if_fail (priv->is_realized);
gsk: Rework GskRenderer and GskRenderNode semantics This commit changes the way GskRenderer and GskRenderNode interact and are meant to be used. GskRenderNode should represent a transient tree of rendering nodes, which are submitted to the GskRenderer at render time; this allows the renderer to take ownership of the render tree. Once the toolkit and application code have finished assembling it, the render tree ownership is transferred to the renderer.
2016-06-22 16:30:36 +00:00
g_return_if_fail (GSK_IS_RENDER_NODE (root));
gsk: Turn GskRenderNode into a pure GTypeInstance Using GObject as the base type for a transient tree may prove to be too intensive, especially when creating a lot of node instances. Since we don't need properties or signals, and we don't need complex destruction semantics, we can use GTypeInstance directly as the base type for GskRenderNode.
2016-06-29 18:05:33 +00:00
g_return_if_fail (priv->root_node == NULL);
gskrenderer: Add gsk_renderer_begin_draw_frame() This way, we can hijack the begin/end draw process and do out own processing before passing it on to GDK.
2016-11-27 15:21:02 +00:00
g_return_if_fail (context == priv->drawing_context);
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
gskrenderer: Add gsk_renderer_begin_draw_frame() This way, we can hijack the begin/end draw process and do out own processing before passing it on to GDK.
2016-11-27 15:21:02 +00:00
if (priv->drawing_context == NULL)
gsk: Add the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
{
if (priv->cairo_context == NULL)
{
g_critical ("The given GskRenderer instance was not created using "
gskrenderer: Add gsk_renderer_begin_draw_frame() This way, we can hijack the begin/end draw process and do out own processing before passing it on to GDK.
2016-11-27 15:21:02 +00:00
"gsk_renderer_create_fallback(), but you forgot to call "
"gsk_renderer_begin_draw_frame().");
gsk: Add the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
return;
}
}
gsk: Make GskRenderer.render() drawing context-agnostic We're going to need to allow rendering on a specific cairo_t in order to implement fallback code paths inside GTK; this means that there will be times when we have a transient GskRenderer instance that does not have a GdkDrawingContext to draw on. Instead of adding a new render() implementation for those cases and then decide which one to use, we can remove the drawing context argument from the virtual function itself, and allow using a NULL GdkDrawingContext when calling gsk_renderer_render(). A later commit will add a generic function to create a transient GskRenderer with a cairo_t attached to it. Renderers inside GSK will have to check whether we have access to a GdkDrawingContext, in which case we're going to use it; or if we have access to a cairo_t and a window.
2016-08-24 15:21:50 +00:00
gsk: Turn GskRenderNode into a pure GTypeInstance Using GObject as the base type for a transient tree may prove to be too intensive, especially when creating a lot of node instances. Since we don't need properties or signals, and we don't need complex destruction semantics, we can use GTypeInstance directly as the base type for GskRenderNode.
2016-06-29 18:05:33 +00:00
priv->root_node = gsk_render_node_ref (root);
gsk_render_node_make_immutable (priv->root_node);
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 GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#ifdef G_ENABLE_DEBUG
gsk_profiler_reset (priv->profiler);
#endif
gsk: Make GskRenderer.render() drawing context-agnostic We're going to need to allow rendering on a specific cairo_t in order to implement fallback code paths inside GTK; this means that there will be times when we have a transient GskRenderer instance that does not have a GdkDrawingContext to draw on. Instead of adding a new render() implementation for those cases and then decide which one to use, we can remove the drawing context argument from the virtual function itself, and allow using a NULL GdkDrawingContext when calling gsk_renderer_render(). A later commit will add a generic function to create a transient GskRenderer with a cairo_t attached to it. Renderers inside GSK will have to check whether we have access to a GdkDrawingContext, in which case we're going to use it; or if we have access to a cairo_t and a window.
2016-08-24 15:21:50 +00:00
GSK_RENDERER_GET_CLASS (renderer)->render (renderer, root);
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 GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
#ifdef G_ENABLE_DEBUG
if (GSK_DEBUG_CHECK (RENDERER))
{
GString *buf = g_string_new ("*** Frame stats ***\n\n");
gsk_profiler_append_counters (priv->profiler, buf);
g_string_append_c (buf, '\n');
gsk_profiler_append_timers (priv->profiler, buf);
g_string_append_c (buf, '\n');
g_print ("%s\n***\n\n", buf->str);
g_string_free (buf, TRUE);
}
#endif
gsk: Turn GskRenderNode into a pure GTypeInstance Using GObject as the base type for a transient tree may prove to be too intensive, especially when creating a lot of node instances. Since we don't need properties or signals, and we don't need complex destruction semantics, we can use GTypeInstance directly as the base type for GskRenderNode.
2016-06-29 18:05:33 +00:00
g_clear_pointer (&priv->root_node, gsk_render_node_unref);
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: Tie render nodes to renderers Render nodes need access to rendering information like scaling factors. If we keep render nodes separate from renderers until we submit a nodes tree for rendering we're going to have to duplicate all that information in a way that makes the API more complicated and fuzzier on its semantics. By having GskRenderer create GskRenderNode instances we can tie nodes and renderers together; since higher layers will also have access to the renderer instance, this does not add any burden to callers. Additionally, if memory measurements indicate that we are spending too much time in the allocation of new render nodes, we can now easily implement a free-list or a renderer-specific allocator without breaking the API.
2016-07-27 15:23:44 +00:00
/**
* gsk_renderer_create_render_node:
* @renderer: a #GskRenderer
*
* Creates a new #GskRenderNode instance tied to the given @renderer.
*
* Returns: (transfer full): the new #GskRenderNode
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
gsk: Tie render nodes to renderers Render nodes need access to rendering information like scaling factors. If we keep render nodes separate from renderers until we submit a nodes tree for rendering we're going to have to duplicate all that information in a way that makes the API more complicated and fuzzier on its semantics. By having GskRenderer create GskRenderNode instances we can tie nodes and renderers together; since higher layers will also have access to the renderer instance, this does not add any burden to callers. Additionally, if memory measurements indicate that we are spending too much time in the allocation of new render nodes, we can now easily implement a free-list or a renderer-specific allocator without breaking the API.
2016-07-27 15:23:44 +00:00
*/
GskRenderNode *
gsk_renderer_create_render_node (GskRenderer *renderer)
{
g_return_val_if_fail (GSK_IS_RENDERER (renderer), NULL);
rendernode: Remove the renderer from the rendernode
2016-11-01 04:47:35 +00:00
return gsk_render_node_new ();
gsk: Tie render nodes to renderers Render nodes need access to rendering information like scaling factors. If we keep render nodes separate from renderers until we submit a nodes tree for rendering we're going to have to duplicate all that information in a way that makes the API more complicated and fuzzier on its semantics. By having GskRenderer create GskRenderNode instances we can tie nodes and renderers together; since higher layers will also have access to the renderer instance, this does not add any burden to callers. Additionally, if memory measurements indicate that we are spending too much time in the allocation of new render nodes, we can now easily implement a free-list or a renderer-specific allocator without breaking the API.
2016-07-27 15:23:44 +00:00
}
gsk: Add GskProfiler to GskRenderer The profiler instance is per-renderer, and is accesible to implementations.
2016-08-03 15:51:21 +00:00
/*< private >
* gsk_renderer_get_profiler:
* @renderer: a #GskRenderer
*
* Retrieves a pointer to the GskProfiler instance of the renderer.
*
* Returns: (transfer none): the profiler
*/
GskProfiler *
gsk_renderer_get_profiler (GskRenderer *renderer)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_val_if_fail (GSK_IS_RENDERER (renderer), NULL);
return priv->profiler;
}
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
static GType
get_renderer_for_env_var (GdkWindow *window)
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: Change GSK_USE_SOFTWARE env var to GSK_RENDERER This way, we can use the variable as more than a boolean flag. This will be useful for Vulkan or D3D renderers.
2016-11-29 12:36:31 +00:00
static GType env_var_type = G_TYPE_NONE;
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: Change GSK_USE_SOFTWARE env var to GSK_RENDERER This way, we can use the variable as more than a boolean flag. This will be useful for Vulkan or D3D renderers.
2016-11-29 12:36:31 +00:00
if (env_var_type == G_TYPE_NONE)
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: Change GSK_USE_SOFTWARE env var to GSK_RENDERER This way, we can use the variable as more than a boolean flag. This will be useful for Vulkan or D3D renderers.
2016-11-29 12:36:31 +00:00
const char *renderer_name = g_getenv ("GSK_RENDERER");
if (renderer_name == NULL)
env_var_type = G_TYPE_INVALID;
else if (g_ascii_strcasecmp (renderer_name, "cairo") == 0)
env_var_type = GSK_TYPE_CAIRO_RENDERER;
else if (g_ascii_strcasecmp (renderer_name, "opengl") == 0)
env_var_type = GSK_TYPE_GL_RENDERER;
gsk: Add skeleton for Vulkan renderer The renderer itself obviously doesn't do anything.
2016-11-29 15:33:14 +00:00
#ifdef GDK_WINDOWING_VULKAN
else if (g_ascii_strcasecmp (renderer_name, "vulkan") == 0)
env_var_type = GSK_TYPE_VULKAN_RENDERER;
#endif
gsk: Change GSK_USE_SOFTWARE env var to GSK_RENDERER This way, we can use the variable as more than a boolean flag. This will be useful for Vulkan or D3D renderers.
2016-11-29 12:36:31 +00:00
else
env_var_type = G_TYPE_INVALID;
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: Change GSK_USE_SOFTWARE env var to GSK_RENDERER This way, we can use the variable as more than a boolean flag. This will be useful for Vulkan or D3D renderers.
2016-11-29 12:36:31 +00:00
return env_var_type;
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
}
static GType
get_renderer_for_backend (GdkWindow *window)
{
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 GDK_WINDOWING_X11
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
if (GDK_IS_X11_WINDOW (window))
return GSK_TYPE_GL_RENDERER;
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
#ifdef GDK_WINDOWING_WAYLAND
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
if (GDK_IS_WAYLAND_WINDOW (window))
return GSK_TYPE_GL_RENDERER;
gsk: Fix build without Wayland
2016-07-25 16:36:33 +00:00
#endif
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 gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
return G_TYPE_INVALID;
}
static GType
get_renderer_fallback (GdkWindow *window)
{
return GSK_TYPE_CAIRO_RENDERER;
}
static struct {
GType (* get_renderer) (GdkWindow *window);
} renderer_possibilities[] = {
{ get_renderer_for_env_var },
{ get_renderer_for_backend },
{ get_renderer_fallback },
};
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 gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
/**
* gsk_renderer_new_for_window:
* @display: a #GdkDisplay
*
* Creates an appropriate #GskRenderer instance for the given @window.
*
* The renderer will be realized when it is returned.
*
* Returns: (transfer full) (nullable): a #GskRenderer
*
* Since: 3.90
*/
GskRenderer *
gsk_renderer_new_for_window (GdkWindow *window)
{
GType renderer_type;
GskRenderer *renderer;
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
GError *error = NULL;
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
guint i;
g_return_val_if_fail (GDK_IS_WINDOW (window), NULL);
for (i = 0; i < G_N_ELEMENTS (renderer_possibilities); i++)
{
renderer_type = renderer_possibilities[i].get_renderer (window);
if (renderer_type == G_TYPE_INVALID)
continue;
renderer = g_object_new (renderer_type,
"display", gdk_window_get_display (window),
NULL);
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
if (gsk_renderer_realize (renderer, window, &error))
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
{
GSK_NOTE (RENDERER, g_print ("Using renderer of type '%s' for display '%s'\n",
G_OBJECT_TYPE_NAME (renderer),
G_OBJECT_TYPE_NAME (window)));
return renderer;
}
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
GSK_NOTE (RENDERER, g_print ("Failed to realize renderer of type '%s' for window '%s': %s\n",
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
G_OBJECT_TYPE_NAME (renderer),
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
G_OBJECT_TYPE_NAME (window),
error->message));
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
g_object_unref (renderer);
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
g_clear_error (&error);
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +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
gsk: Add gsk_renderer_new_for_window() and remove gsk_renderer_get_for_display(). This new function returns a realized renderer. Because of that, GSK can catch failures to realize, destroy the renderer and try another one. Or in short: I can finally use GTK on Weston with the nvidia binary drivers again. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:27:21 +00:00
g_assert_not_reached ();
return NULL;
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 the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
gsk: Add internal Renderer.create_cairo_surface() We need an overridable entry point for GskRenderer to create Cairo surfaces. Implementations of GskRenderer can override create_cairo_surface() to create efficient surfaces, possibly with zero copies involved, depending on the GDK backend.
2016-10-31 16:26:50 +00:00
cairo_surface_t *
gsk_renderer_create_cairo_surface (GskRenderer *renderer,
cairo_format_t format,
int width,
int height)
{
g_return_val_if_fail (GSK_IS_RENDERER (renderer), NULL);
g_return_val_if_fail (width > 0 && height > 0, NULL);
return GSK_RENDERER_GET_CLASS (renderer)->create_cairo_surface (renderer, format, width, height);
}
gsk: Add the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
static void
gsk_renderer_set_cairo_context (GskRenderer *renderer,
cairo_t *cr)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_clear_pointer (&priv->cairo_context, cairo_destroy);
if (cr != NULL)
priv->cairo_context = cairo_reference (cr);
}
cairo_t *
gsk_renderer_get_cairo_context (GskRenderer *renderer)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
return priv->cairo_context;
}
gskrenderer: Add gsk_renderer_begin_draw_frame() This way, we can hijack the begin/end draw process and do out own processing before passing it on to GDK.
2016-11-27 15:21:02 +00:00
GdkDrawingContext *
gsk_renderer_begin_draw_frame (GskRenderer *renderer,
const cairo_region_t *region)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_val_if_fail (GSK_IS_RENDERER (renderer), NULL);
g_return_val_if_fail (region != NULL, NULL);
g_return_val_if_fail (priv->drawing_context == NULL, NULL);
priv->drawing_context = GSK_RENDERER_GET_CLASS (renderer)->begin_draw_frame (renderer, region);
return priv->drawing_context;
}
void
gsk_renderer_end_draw_frame (GskRenderer *renderer,
GdkDrawingContext *context)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
g_return_if_fail (GSK_IS_RENDERER (renderer));
g_return_if_fail (GDK_IS_DRAWING_CONTEXT (context));
g_return_if_fail (priv->drawing_context == context);
priv->drawing_context = NULL;
GSK_RENDERER_GET_CLASS (renderer)->end_draw_frame (renderer, context);
}
gsk: Add the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
/**
* gsk_renderer_create_fallback:
* @renderer: a #GskRenderer
* @viewport: the viewport for the fallback renderer
* @cr: a Cairo context
*
* Creates a fallback #GskRenderer using the same display and window of
* the given @renderer, and instructs it to render to a given Cairo
* context.
*
* Typically, you'll use this function to implement fallback rendering
* of #GskRenderNodes on an intermediate Cairo context, instead of using
* the drawing context associated to a #GdkWindow's rendering buffer.
*
* Returns: (transfer full): a newly created fallback #GskRenderer instance
*
gsk: Bump up all version annotations GSK is part of the 4.0 development cycle.
2016-10-18 10:37:10 +00:00
* Since: 3.90
gsk: Add the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
*/
GskRenderer *
gsk_renderer_create_fallback (GskRenderer *renderer,
const graphene_rect_t *viewport,
cairo_t *cr)
{
GskRendererPrivate *priv = gsk_renderer_get_instance_private (renderer);
GskRenderer *res;
g_return_val_if_fail (GSK_IS_RENDERER (renderer), NULL);
g_return_val_if_fail (cr != NULL, NULL);
res = g_object_new (GSK_TYPE_CAIRO_RENDERER,
"display", priv->display,
"scale-factor", priv->scale_factor,
"viewport", viewport,
NULL);
gsk_renderer_set_cairo_context (res, cr);
gskrenderer: Add GError argument to gsk_renderer_realize() This way, we don't spam criticals when GL is not available. Instead, we print a useful debug message to stderr and continue with the Cairo renderer. Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
2016-11-29 03:51:07 +00:00
gsk_renderer_realize (res, priv->window, NULL);
gsk: Add the ability to create fallback renderers While porting GTK to GskRenderer we noticed that the current fallback code for widgets using Cairo to draw is not enough to cover all the possible cases. For instance, if a container widget still uses GtkWidget::draw to render its children, and at least one of them has been ported to using render nodes instead, the container won't know how to draw it. For this reason we want to provide to layers above GSK the ability to create a "fallback" renderer instance, created using a "parent" GskRenderer instance, but using a Cairo context as the rendering target instead of a GdkDrawingContext. GTK will use this inside the gtk_widget_draw() implementation, if a widget implements GtkWidgetClass.get_render_node().
2016-08-25 10:31:56 +00:00
return res;
}
Reference in New Issue Copy Permalink