A color matrix node that contains a transform node can also be expressed
the other way around, as a transform node containing a color matrix
node.
In the general case, the color matrix node will have to draw its
child to a texture so it can color every pixel of that texture, but the
renderers can short-cut this if the child of the color matrix node is
already a texture node. So if we have a node tree like
Color Matrix
- Transform
- Texture
The renderer would have to either check the grandchild of the color
matrix or simply fall back to rendering the transform node to a texture.
In the new configuration:
Transform
- Color Matrix
- Texture
The renderer can easily see that the child node of the color matrix node
is a texture, and skip rendering it to a texture.
This is for example happening in current Adwaita for spinners, which are
rotated symbolics.
Make the API expect a tranform of the proper category instead of
doing the check ourselves and returning TRUE/FALSE.
The benefit is that the mai use case is switch (transform->category)
statements and in those we know the category and don't need to check
TRUE/FALSE.
Using the wrong matrix will now cause a g_warning().
Instead of gtk_snapshot_offset(), provide a full set of functions
kept in sync with GtkTransform APIs.
On top of that, add gtk_snapshot_save() and gtk_snapshot_restore()
mirroring cairo_save()/restore() that allow saving a snapshot's
transform state.
The code didn't change, it was just shuffled around to make the
with_bounds() versions of the text rendering unnecessary and instead
pass through the generic append_node() path.
Instead of just tracking 2 integer translate_x/y coordinates, tracka a
full GtkTransform.
When creating actual nodes, if the transform is simple enough, just
create the node in a way that makes use of the transform. If the
node, can't represent the transform, just push a transform node instead
and automatically pop that node with the next gtk_snapshot_pop() call.
They were a neat idea while they lasted. But now, it's time for
categorized transform nodes, where matrices with
GSK_MATRIX_CATEGORY_2D_TRANSLATE are the exact replacement.
Renderers have not been adapted for this purpose, so they (continue to)
run slow paths.
Instead of style + rect_of_one_box, pass the new GtkCssBoxes object.
This has the nice side effect that when drawing background + border +
outline, we only compute all the boxes we need once.
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
