gtk_css_node_insert_before/after can easily create cycles
which later lead to stack overflows. Even if we're not
catching all cycles here, at least we can detect obviously
invalid arguments, such as inserting a node next to itself.
When we reuse styles that didn't change across changes to the source
CSS, make sure we clear the caches. Otherwise child nodes will pick up
styles from the old source CSS.
In commit 2c61316677 we avoided emitting
the style-changed signal if no CSS property changed.
Unfortunately, this also caused CSS styles to not be updated when
animations started if those animations did not change any CSS value
immediately. In those cases the animation would just never start.
The obvious example was the spinner.
Catch the case where a CSS style did not change and don't emit the
style-changed signal in that case.
This saves not only the emission of the signal, but also doesn't cause
invalidation in child nodes, which would previously get a PARENT_STYLE
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
We were just catching the previous sibling before. Now we properly
invalidate all previous siblings (and also all other wiblings, but we
can think about optimizing that later).
The previous code was crashing when used as the returned classes array
would have been invalid after the first deletion. So if a 2nd class
would be deleted, invalid memory might have been referenced.
We can actually share :first-child/:last-child related things now,
because we special case them. So the only positions we cannot cache are
nth-child/nth-last-child.
This should take care of a lot of Adwaita's styling.
gtk_css_node_set_after/before() are now called
gtk_css_node_insert_after/before().
This brings them in line with other similar APIs (ie GtkListStore). And
it allows easier usage of the API (see changes to gtkbox.c).
This allows monitoring the CSS tree. For now, moving a child to a
different position relative to its siblings while keeping the same
parent will cause a child-added + child-removed emission.
We need to properly track if a node needs to propagate invalidation
state information to its children. We didn't do this properly before and
that could lead to us forgetting to invalidate nodes in corner cases.
Do not propagate the TIMESTAMP change through the node tree, as that
causes lots of uneeded markings of nodes as invalid.
Instead, walk the node tree and find the nodes that have a non-static
style and only invalidate timestamps on those.
Only invalidate timestamps if the node is marked as invalid. We overload
the meaning of "invalid" as "tracks timestamps".
While I don't like the way this is written, it is an important
optimization because 95+% of nodes don't animate so timestamps don't
matter to them. But timestamps are invalidated 60x per second.
We don't return a NULL style to mean "no changes" anymore, instead
we check new_style == old_style to mean that.
Make sure the code reflects this, otherwise we'll send
GTK_CSS_CHANGE_PARENT_STYLE invalidations everywhere and screw up
performance.
Now that the widget node recomputes styles on update_style() we can just
call it during validate(). That way, we don't need the widget node to
manually compute its style.
... and pass it to the API that computes new styles.
A special timestamp of 0 means "please don't animate" and is used when
no frame clock is available for a node.
This is mainly an attempt to merge the update_style() and validte()
vfuncs. Code is not there yet, but that's the idea.
Also, gtk_css_node_set_style() should not be public. And this gets
closer to that goal, too.
After measuring it, I realized the optimization never triggers for
Adwaita and rarely ever triggers for simple themes. So it is not
useful to keep it around.
This allows adding more API for it.
It also includes code that tracks modifications and invalidates siblings
and their positions whenever nodes get added or removed.
The node declaration has the same functionality as
gtk_css_node_declaration_add_to_widget_path(). So instead of using that
function on a path, you can use the original path and the declaration in
a matcher.
So far the vfunc is kinda quirky (the path argument is an out argument
for something you have to free when you're done with the matcher), but
I'm about to change that.
The parent refs the child, so gtk_css_node_set_parent() adds/removes a
reference.
We should probably refactor this so that we name the function
parent.add(node) instead of node.set_parent(parent) - makes the
refcounting more clear.
- GtkCssWidgetNode
for style contexts owned by a widget
- GtkCssPathNode
for style contexts using a GtkWidgetPath
- GtkCssTransientNode
for nodes created with gtk_style_context_save()/restore()
The functionality of it is supposed to grow, so better put it in a
custom file early.
This is just a naive split so far, the next patches will split things
further.
