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

75 lines
2.9 KiB
C
Raw Normal View History

Initial implementation of GSK rendering pipeline GSK is conceptually split into two scene graphs: * a simple rendering tree of operations * a complex set of logical layers The latter is built on the former, and adds convenience and high level API for application developers. The lower layer, though, is what gets transformed into the rendering pipeline, as it's simple and thus can be transformed into appropriate rendering commands with minimal state changes. The lower layer is also suitable for reuse from more complex higher layers, like the CSS machinery in GTK, without necessarily port those layers to the GSK high level API. This lower layer is based on GskRenderNode instances, which represent the tree of rendering operations; and a GskRenderer instance, which takes the render nodes and submits them (after potentially reordering and transforming them to a more appropriate representation) to the underlying graphic system.
2016-03-17 13:48:19 +00:00
/* 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/>.
*/
#ifndef __GSK_RENDERER_H__
#define __GSK_RENDERER_H__
Use a single compilation symbol We use a compilation symbol in our build to allow the inclusion of specific headers while building GTK, to avoid the need to include only the global header. Each namespace has its own compilation symbol because we used to have different libraries, and strict symbol visibility between libraries; now that we have a single library, and we can use private symbols across namespaces while building GTK, we should have a single compilation symbol, and simplify the build rules.
2019-11-27 13:33:43 +00:00
#if !defined (__GSK_H_INSIDE__) && !defined (GTK_COMPILATION)
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
#error "Only <gsk/gsk.h> can be included directly."
#endif
#include <gsk/gsktypes.h>
#include <gsk/gskrendernode.h>
G_BEGIN_DECLS
#define GSK_TYPE_RENDERER (gsk_renderer_get_type ())
#define GSK_RENDERER(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj), GSK_TYPE_RENDERER, GskRenderer))
#define GSK_IS_RENDERER(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), GSK_TYPE_RENDERER))
docs: Annotate GskRenderer
2020-12-01 14:17:59 +00:00
/**
* GskRenderer:
*
* Base type for the object managing the rendering pipeline
* for a #GdkSurface.
*/
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 _GskRendererClass GskRendererClass;
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
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
GType gsk_renderer_get_type (void) G_GNUC_CONST;
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
renderer: Remove display property Renderers don't need a display until they get realized. And once they get realized, they can look up the display from the surface.
2019-03-09 12:36:14 +00:00
GskRenderer * gsk_renderer_new_for_surface (GdkSurface *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
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
renderer: Remove display property Renderers don't need a display until they get realized. And once they get realized, they can look up the display from the surface.
2019-03-09 12:36:14 +00:00
GdkSurface * gsk_renderer_get_surface (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
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
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
gboolean gsk_renderer_realize (GskRenderer *renderer,
Continue renaming window to surface This renames a lot of arguments, local variables and functions.
2018-03-21 10:49:14 +00:00
GdkSurface *surface,
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);
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
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);
renderer: Make gsk_renderer_is_realized() public ... and add a property for it.
2019-03-09 12:59:03 +00:00
GDK_AVAILABLE_IN_ALL
gboolean gsk_renderer_is_realized (GskRenderer *renderer);
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
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
GskTexture => GdkTexture We want this thing to replace GdkPixbuf, so it has to live in GDK.
2017-11-02 20:39:00 +00:00
GdkTexture * gsk_renderer_render_texture (GskRenderer *renderer,
gsk: Add gsk_renderer_render_texture() ... and implement it for the Cairo renderer. It's an API that instructs a renderer to render to a texture. So far this is mostly meant to be used for testing, but I could imagine it being useful for rendering DND icons.
2016-12-21 19:23:46 +00:00
GskRenderNode *root,
const graphene_rect_t *viewport);
The big versioning cleanup Remove all the old 2.x and 3.x version annotations. GTK+ 4 is a new start, and from the perspective of a GTK+ 4 developer all these APIs have been around since the beginning.
2018-02-05 19:13:20 +00:00
GDK_AVAILABLE_IN_ALL
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
void gsk_renderer_render (GskRenderer *renderer,
GskRenderNode *root,
gsk: Fold gsk_renderer_begin_draw_frame() into renderer It doesn't need to be exported anymore. As a side effect, the inspector no longer has any information about the render region, so remove the code that was taking care of that.
2018-03-27 23:29:39 +00:00
const cairo_region_t *region);
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_END_DECLS
#endif /* __GSK_RENDERER_H__ */
Reference in New Issue Copy Permalink