Most of the time, the GtkSnapshot objects we create while snapshotting
widgets don't end up containing all that many nodes or states in their
respective node or state stack. This undermines the amortized allocation
behavior of the G(Ptr)Array we use for the stacks. So instead, use the
(until now unused) parent_snapshot GtkSnapshot* passed to
gtk_widget_create_render_node and reuse its node and state stack.
We do not avoid allocating a new GtkSnapshot object, but we do avoid
allocating a ton of G(Ptr)Array objects and we also avoid realloc'ing
their storage.
Any data that is later fed to graphene must be
allocated with proper alignment, if graphene
uses SSE2 or GCC vector instructions.
This adds custom array code (a streamlined copy
of GArray with all unnecessary bells and whistles removed),
which is then used for the state_stack instead of GArray.
There's also a runtime check for the size of GtkSnapshotState
itself being a multiple of 16. If that is not so, any array
elements past the 0th element will lose alignment.
There are probably struct attributes that can
make GtkSnapshotState always have size that is a multiple
of 16, but we'll burn that bridge if we cross it.
A container node inside another container node doesn't make a lot of
sense, we can instead just use the parent container node and add the
child container node's children to it directly.
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.
