Commit Graph

107 Commits

Author SHA1 Message Date
Matthias Clasen
7b204b0eea Add an offset to render nodes
This will let us account for the difference between
clip and allocation.
2016-10-18 11:49:11 +01:00
Emmanuele Bassi
a8a8f97511 gsk: Take into account the scaling factor
We need to apply a scaling factor whenever we deal with user-supplied
coordinates, like:

 - when creating textures
 - when setting up the viewport
 - when submitting the scene
2016-10-18 11:49:10 +01:00
Emmanuele Bassi
3d90a070d5 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-10-18 11:49:10 +01:00
Emmanuele Bassi
81e992e1ff gsk: Store blend mode in the render node 2016-10-18 11:49:07 +01:00
Emmanuele Bassi
b8a92dfa0e 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-10-18 11:49:06 +01:00
Emmanuele Bassi
074c77e7ac 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-10-18 11:29:34 +01:00
Emmanuele Bassi
7afdd3fdb5 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-10-18 11:29:34 +01:00