If widgets want to clip things, they now need to do it themselves.
By not taking care of clip, we avoid the need to track clip. And by not
tracking clip, we can avoid all unnecessary cache invalidations that we
were doing for render nodes whenever the clip changed.
And when you are scrolling, the clip changes *a lot*.
1. Pass clip rectangles to gtk_snapshot_push_state() that point into
the state array.
2. g_array_set_size(len+1) the state array
3. Make that function realloc() the state array.
4. The clip rectangle now points into invalid memory
5. Use the clip array
This patch fixes things by moving step 5 to before step 2.
This allows being more specific about the size.
It's useful in particular when the resulting render nodes might be
too small for the size, not only when they are too large. For the
latter case, using a clip node would be enough.
It also requires adding a clip node when rendering the resulting
paintable, but that should be optimized out by GtkSnapshot when not
necessary.
When the clip changes that is passed to a snapshot function, we need to
create eventual cached render nodes because they might not have drawn
their whole area before.
Fixes issues with redrawing when scrolling.
This requires a bunch of refactorings:
1. Don't pass the current clip region to gtk_widget_snapshot()
so we don't create full widget contents
3. Have a widget->priv->draw_needed that we invalidate on every
queue_draw() call and set on every snapshot()
2. In queue_draw(), walk the widget chain to invalidate the
render nodes of all parents
This is the equivalent snapshot function to pango_cairo_show_layout().
Not to be confused with gtk_snapshot_render_layout(), which is the
equivalent to gtk_render_layout().
In certain cases, we might create large cairo nodes, resulting in
surfaces so large, cairo can't handle them. Fix this by limiting the
cairo node to the current clip region.
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.
This way, we can also clip the created node bounds to the current clip
of the GtkSnapshot. This works as long as we don't modify the start and
end points, and happens all the time while rendering.
Clipping a color node is trivial so we do it here directly since that
might later save the entire clip node as well as freeing the fragment
shaders from coloring lots of pixels that will be clipped away.
Color matrix nodes as the child of other color matrix nodes can happen
quite frequently as a result of CSS. To ease the renderer
implementations, collapse chains of color matrix nodes into one.
If the rounded clip node is rectilinear, we can simplify it to a normal
clip node. If not, we really need to use a rounded clip node. In both
cases, we can do the same check we do when collecting normal clips and
avoid the clip node altogether if the child node does not get clipped
anyway.
This saves between 3 and 10 nodes in the widget factory, depending on
what page gets rendered.
Clip nodes have a clip rect and we only need to actually create a clip
node if any child node gets clipped at all. If the clip rect conains the
child node bounds entirely, we don't need a clip node.
I got a lot of "clip in clip" cases, for example a CellClip with a
CellTextClip inside. It is really trivial to merge these when we
pop and makes it easier for all backends, so lets do that.
The Vulkan renderer creates a fallback surface for each shadow
node, even if we end up not rendering anything to it. Avoiding
this is a nice optimization.
An empty container has the same effect as transparency
with the cairo renderer, but creates black with Vulkan.
To avoid this, explicitly use a transparent color node.
This fixes the css blendmode example in gtk4-demo with
the Vulkan renderer.
This is important since _push_state returns a pointer into a GArray
which could be invalidated and point to garbage after the subsequent
push_state call.
Instead of creating one GPtrArray per GtkSnapshotState and saving nodes
in there, create one GPtrArray per snapshot and assign a
start_node_index to every GtkSnapshotState as well as a n_nodes variable
so every state knows which nodes belong to it.
This showed up in profiles in certain scenarios, so export a
_get_n_shadows getter instead and let callers provide a sufficiently
large allocated array of GskShadows, which we can use with
g_alloc/g_newa.
We can't pass the same string to two different snapshot states since
removing one of them will free the passed string, so just create another
one for the second state.
gtk_snapshot_pop() => removed
gtk_snapshot_pop_and_append() => gtk_snapshot_pop()
So now there is no way to get a rendernode out of the snapshotting API
until you gtk_snapshot_finish().
... and use it.
The function is a bit awkward because it requires 2 calls to
gtk_snapshot_pop(), but once you accept that, it's very convenient to
use, as can be seen by the 2 implementations.
We already take ints when setting the translation, so it can't
currently take any other values. Additionally, I was seeing large
costs in int -> double -> int for the rects in
gtk_snapshot_clips_rect(), as all callers really are ints (widget
allocations) and the clip region is int-based.
This change completely cleared a 2% rectangle_init_from_graphene from
the profile and is likely to have nice performance effects elsewhere
too.
This means we allocate the collect data with the state, avoiding
an extra allocation. Also, a union means every state object
is the same size and we could reuse the state objects.
... and make the icon rendering code use it.
This requires moving even more shadow renering code into GSK, but so be
it. At least the "shadows not implemented" warning is now gone!
It is now possible to call push() subfunctions for simple container
nodes with just a single child. So you can for example
gtk_snapshot_push_clip() a clip region that all the nodes that get
appended later will then obey.
gtk_snapshot_pop() will then not return a container node, but a clip
node containing the container node (and similar for the transform
example).
This is implemented internally by providing a "collect function" when
pushing that is called when popping to collects all the accumulated
nodes and combine them into the single node that gets returned.
To simplify things even more, gtk_snapshot_pop_and_append() has been
added, which pops the currently pushed node and appends it to the
parent.
The icon rendering code has been converted to this approach.
Instead of appending a container node and adding the nodes to it as they
come in, we now collect the nodes until gtk_snapshot_pop() is called and
then hand them out in a container node.
The caller of gtk_snapshot_push() is then responsible for doing whatever
he wants with the created node.
Another addigion is the keep_coordinates flag to gtk_snapshot_push()
which allows callers to keep the current offset and clip region or
discard it. Discarding is useful when doing transforms, keeping it is
useful when inserting effect nodes (like the ones I'm about to add).
Instead of having a setter for the transform, have a GskTransformNode.
Most of the oprations that GTK does do not require a transform, so it
doesn't make sense to have it as a primary attribute.
Also, changing the transform requires updating the uniforms of the GL
renderer, so we're happy if we can avoid that.
gsk_render_node_get_bounds() still exists and is computed via vfunc
call:
- containers dynamically compute the bounds from their children
- surface and texture nodes get bounds passed on construction
We want to split nodes into containers and nodes that do actual drawing.
So pushing nodes that do drawing is exactly the wrong thing.
Also fix up GtkPopover. There's no need for it to push anything.
And use this to cull widgets and gadgets that are completely outside the
clip region.
A potential optimization is to apply this clip region to cairo contexts
created with gtk_snapshot_append_cairo_node(), but for that we'd need to
apply the inverse matrix to the clip region, and that causes rounding
errors.
Plus, I hope that cairo drawing becomes exceedingly rare so it won't be
used for the whole widget factory like today (which might also explain
why no culling happens in the widget factory outside the header bar.
The equivalent to cairo_matrix_multiply (a, b, c) is
graphene_matrix_multiply (c, b, a).
graphene_matrix_multiply (a, b, c) may not be called with b and c being
the same matrix.
We do no longer bind textures to a renderer, instead they are a way for
applications to provide texture data.
For now, that's it. We've reverted to uploading it from scratch every
frame.
