... to a bunch of functions.
This requires a tiny change to the heuristics for the style cache - we
now cache styles when they have the same style provider as their parent
instead of when they have the default provider - but that change doesn't
have any effect in practice.
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.
Instead of passing the style declaration, take the node's style
declaration. Add arguments to allow overriding the state for the one
case where this didn't work.
The code is confusing the stylecontext=>node transition, so I'll remove
it.
WIth the recent introduction of the parent style cachen, I'm not sure
it's worth it at all. Some crude benchmarking suggests a slight speedup
when removing the cache.
So no guarantees about adding it back later.
- 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.
This guarantees we only create 1 extra style cascade in total for hidpi
and not one per style context.
Style cascades are now nested like this:
GtkSettings root cascade (scale == 1)
|
+-- GtkSettings per scale cascade (for any scale, no custom providers)
|
+-- GtkStyleContext custom cascade (for any scale, custom providers)
This requires a bunch of care when changing cascade-related properties
inside GtkStyleContext, so that it ends up with a properly setup
cascade, but I think I got those cases right.
The only thing we don't do yet is reverting to a GtkSettings cascade
when the last custom provider is removed from a custom cascade.
Instead of asserting, just print a g_warning() and try to work around
the problem.
I hope that g_warning() isn't too spammy for people that are hit with
it.
Also clarify the docs that not restore()ing after a save() is a bad
idea.
https://bugzilla.gnome.org/show_bug.cgi?id=743101
When creating the query path, explicitly specify if it's for a root node
or for a child. Relying on gtk_style_context_is_saved() is unreliable
(for example when updating the cache).
This gets rid of a bunch of awkward transitions. It's not a perfect
solution to the problem of "should we transition from this state" but it
gets rid of the ugliest offenders.
If a gtk_style_context_invalidate() is called on a widget's style
context (which nobody should ever do, sheesh!) and we're animating, stop
the animations.
Fixes crashers in Nautilus.
We need to clear the cache manually on full revalidates because
_gtk_css_change_for_child() will clear the full revalidation flags.
And then gtk_style_context_update_cache() will not do the right thing
(which is to clear itself).
Because we can switch from animating to non-animating pretty much
anywhere, do the check for animations unconditionally instead of trying
to cram it into the correct if path (and failing).
We now cache the results of lookups on the parent GtkCssStyle. This
allows sharing styles between widgets (recursively). However, this
only works if the styles can't potentially depend on siblings -
neither directly via sibling selectors or via position pseudo-classes
like :first-child.
Unfortunately, Adwaita currently uses first-child a lot, and in
particular for labels, which are the most common widgets.
The big benefits of this change are both less CPU - due to not needing
to compute styles again - and less memory usage - due to sharing of
the styles between widgets. Here's some nonscientific numbers I
collected while pondering the usefulness of this patch:
glade glade widget
demo demo factory
runtime styles styles
Adwaita before 19.1s 5800 1150
Adwaita now 18.9s 3800 970
Adwaita hacked now 14.5s 3100 910
simple before 11.3s 5800 1150
simple now 10.8s 1300 590
Adwaita: Adwaita as provided by GTK
Adwaita hacked: Adwaita with the first/last-child for GtkLabel removed
simple: A 250 lines simple GTK theme I use for testing
before: This patch not applied
now: this patch applied
glade demo runtime: Starting glade opening a large file and closing it
glade demo styles: GtkCssStaticStyle objects after opening glade with
the large file as per inspector
widget factory styles: GtkCssStaticStyle objects after startup as per
inspector
Previously we looked at the save/restore state when determining the
parent. This is wrong in the case where we're updating the cache though.
So we now save the parent in the style info.
