summaryrefslogtreecommitdiff
path: root/gsk/gskrenderer.h
Commit message (Collapse)AuthorAgeFilesLines
* gsk: Add gsk_renderer_render_texture()Benjamin Otte2016-12-231-0/+5
| | | | | | | | ... 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.
* gsk: Remove nonexisting functionsBenjamin Otte2016-12-231-8/+0
| | | | | The function was removed when gsk_render_node_draw() was and gsk_renderer_realize() was refactored respectively.
* gsk: Add gsk_container_node_new()Benjamin Otte2016-12-201-3/+0
| | | | | It replaces gsk_renderer_create_render_node() which was doing the eact same thing, only taking an unused extra argument.
* gskrenderer: Add gsk_renderer_begin_draw_frame()Benjamin Otte2016-12-051-1/+5
| | | | | This way, we can hijack the begin/end draw process and do out own processing before passing it on to GDK.
* gskrenderer: Store the GL contextBenjamin Otte2016-12-051-0/+2
| | | | | | | And use it to create the drawing context with it. Note that this doesn't yet have any effect and is all infrastructure preparation work.
* gskrenderer: Add GError argument to gsk_renderer_realize()Benjamin Otte2016-11-301-1/+2
| | | | | | | 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>
* gsk: Add gsk_renderer_new_for_window()Benjamin Otte2016-11-301-1/+1
| | | | | | | | | | | | 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>
* gsk: Change gsk_renderer_realize()Benjamin Otte2016-11-301-1/+2
| | | | | | | 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>
* rendernode: Require passing a renderer to get_draw_context()Benjamin Otte2016-11-011-1/+0
| | | | | | This is in preparation of making render nodes independent of the renderer, so that they can be rendered multiple times with different renderers.
* gsk: Bump up all version annotationsEmmanuele Bassi2016-10-181-14/+14
| | | | GSK is part of the 4.0 development cycle.
* gsk: Add the ability to create fallback renderersEmmanuele Bassi2016-10-181-0/+5
| | | | | | | | | | | | | | | | | | 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().
* gsk: Remove GskRenderer:auto-clearEmmanuele Bassi2016-10-181-5/+0
| | | | | We control the clearing inside each GskRenderer implementation, and we don't allow providing a target surface any more.
* gsk: Remove :use-alpha from GskRendererEmmanuele Bassi2016-10-181-5/+0
| | | | | It's unused, and we always assume we render with an alpha channel enabled because it's 2016.
* gsk: Move scaling filters to GskRenderNodeEmmanuele Bassi2016-10-181-8/+0
| | | | | | | | The renderer will always use nearest-neighbor filters because it renders at 1:1 pixel to texel ratio. On the other hand, render nodes may be scaled, so we need to offer a way to control the minification and magnification filters.
* gsk: Drop modelview/projection from GskRenderer APIEmmanuele Bassi2016-10-181-12/+0
| | | | | | | The details of the modelview and projection matrices are only useful for the GL renderer; there's really no point in having those details available in the generic API — especially as the Cairo fallback renderer cannot really set up a complex modelview or a projection matrix.
* gsk: Tie render nodes to renderersEmmanuele Bassi2016-10-181-0/+4
| | | | | | | | | | | | | | | | | 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.
* gsk: Rework GskRenderer and GskRenderNode semanticsEmmanuele Bassi2016-10-181-19/+12
| | | | | | | | | | | 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.
* Initial implementation of GSK rendering pipelineEmmanuele Bassi2016-10-181-0/+113
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.
View Lorry Controller Status