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.
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.
