Introduce refcounted structs for groups of related css properties,
and use them to store the style values. Both GtkCssStaticStyle and
GtkCssAnimatedStyle fill in the structs in GtkCssStyle, and we
can avoid vfuncs for value access, which should be much faster.
We can even start accessing style->core->color directly.
Add GtkWidget API for adding and removing style classes, as well as
checking whether a widget has a style class applied.
Everyone has to go through GtkStyleContext for this these days but with
GtkStyleContext eventually going away, it makse sense for GtkWidget to
have API for this.
Instead of foreaching through all the previous selectors every time we
bloom-filter, just bloom-filter the current element and return a special
value if that filter fails (FALSE). If that happens, don't try
filter-matching more nodes in the caller as we know it's an abort.
We have so many properties that it is basically impossible that all of
them are set and the time spent checking is higher than the time saved
if it does indeed happen.
This was a good idea back in GTK3 when popovers were toplevels, but now
they're regular child widgets, so they should behave that way.
Also, with the introduction of the bloom filter, gtk_css_node_validate()
now assumes it's only called on root nodes, so assert that that is the
case.
Instead of a foreach() function, introduce an iterator, so that the
caller can drive the iteration.
This allows doing stuff inbetween callbacks and avoids closures when
more than one data object should be passed.
As a side effect I even get a small, but noticeable performance
improvement in the 2-10% range depending on benchmark, I guess that's
because there's no function pointer passing going on anymore.
The FileChooser ToolKit (fctk) had its own machinery to handle default
sizes which was completely busted and trying to marshal random numbers
through the widget hierarchy that maybe made sense in 2012 but don't do
now.
Get rid of it, just keep the dialog's GSetting - which funnily enough
used to be written by the dialog but written by the widget.
But that's fctk for you.
Instead of just doing radical change matching on the node itself, also
consider the parent nodes via the bloom filter.
This means a radical change is now also one where the parent
name/id/classes change, but since that's considered a radical change on
the parent already, those things are slow anyway.
Improves the benchmark times for CSS validation during backdrop
transitions in widget-factory from 45ms to 35ms on my machine.
:not() selectors cannot be radical because the bloomfilter only knows if
a value is set in any of the nodes, but cannot determine the opposite
(if a value is not set in at least one node), but that would be required
for:not() selectors.
However, this is very unlikely to happen in the real world, so it's not
worth optimizing.
Unfortunately, change tracking could know this, so by excluding the
:not() selectors from radical changes, the change tracking will now pick
them up. If that turns out to be a performance problem, we need to add a
special category for radical not filters, so change tracking and bloom
filters can deal with them.
The testcase demonstrating the problem in widget-factory has been
extrated and added.
Add a fast path for parent selector matching that uses a bloom filter to
quickly discard selectors that can't possibly match.
Keep in mind that we match using a bloom filter, so we might
accidentally include too many selectors when hash/bucket collisions
occur.
That's not a correctness problem though, because we'll do a real check
afterwards.
The idea for this change is taken from browsers, in particular WebKit.
The reason for this is simply that I want to get hash functions that
have their values close together, so they can fit in a smaller range
(the goal here is 12 bits). By using GQuark, we get consecutive numbers
starting with 1 (and applications have <1000 quarks usually), whereas
interned strings can be all over the place.
As a side effect we also save 64 bytes per declaration.
The function was not selector-specific, so putting it with all the other
utility functions makes more sense.
Also use the utility function in the node declaration printing.
This is not meant to be a full GtkCalendar conversion to use widgets
instead of custom drawing, but we lost the arrows in the calendar header
when builtin icons were removed. Using proper button for the year/month
buttons brings them back.
Use the new gtk_css_dimension_value_is_zero() to check if we really need
to e.g. apply a border radius at all.
We compute css boxes a lot so this makes sense here, it especially shows
up during pick(), where we need the border box.
We want to differentiate what requires recreating the
texture and what doesn't. In particular, the current
flags are not handling symbolic icons right.
Count how often each tree node is visited, and print the number
at the end. This gives a good indication what selectors are costly
and should be avoided. #ifdefed out.
This was broken in various ways; Tabbing between pages
was causing segfaults, and using the hover state like
this does not work anymore, with hover now being completely
managed by GTK. Use focus instead, and also fix up the
style.
- many moons and some iterations later, these are the suggested
general typographic styles. Already being referenced in apps like
Banner Viewer (for now shipping custom definitions)
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/1808
This call is not necessary, because gtk_css_node_set_parent() does the
right thing. (It probably hasn't been necessary for years, but I'm
not gonna try my luck on GTK3 at this stage.)
This code is usually called the first time
gtk_widget_get_style_context() is called on a widget and its style
context gets create. At that point however, the css nodes are in the
right place already, so no invalidation should happen.
When the border-style special cases were moved in
c687f485fd, the one for outline-width was lost.
Make the code more compact, and bring the special
case back.
Previously, we wrapped all GtkCssShadowValues in a GtkCssShadowsValue,
even if it was just one shadow. This causes an unnecessary bloat in
css values.
Make each GtkCssShadowValue able to handle multiple shadows instead, and
use gtk_css_shadow_value* API everywhere.
As per the previous commit, this is unnecessary.
Even with the small amount of css values we mark as is_computed, we
already skip computing over 60% of them like this during the startup of
the widget factory.
When a css value has "child" css values (e.g. a linear gradient has
several color stop css values) which are all computed (won't change when
compute() is called on them), we want to skip computing the entire
subtree.
Since css values are immutable, we can set the is_computed flag at
construct time.
Since GtkCssValue instances are 0-initialized in _gtk_css_value_alloc,
the default for is_computed it FALSE. This commit only sets it to TRUE
in a few cases, such as various "none" singleton values which will never
change. Later commits will refine this and set it for more values.
Themes might use e.g. image(red), which is a constant value and will
never change. In that case, the fallback image has ->color set, but not
->images. If that's the case and the computed color is the same as
the one we already have, just return the already existing image.
The differenciation between a literal color value and an RGBA value
caused problems in various situations. Just treat the two the same but
don't allow access to the rgba value of a non-literal color value.
This gets rid of around 1.6k rgba values in the widget-factory.
we don't need to do the calculation at all if the progress is 0 or 1
anyway.
We also sometimes transition from 0 to 0 etc., so we can short-circuit
that as well by doing the fast pointer-equality check and relying on the
singletons.
Most corners are square, so x == y. In that case, just accept either of
them. This makes the corner value unnecessary.
In fact none of the corner values in the widget-factory are needed, so
this spares us around 500 corner value allocations.
css value stats before:
GtkCssBgSizeValue: 23
GtkCssIdentValue: 25
GtkCssPositionValue: 81
GtkCssCornerValue: 556
GtkCssArrayValue: 143
GtkCssStringValue: 33
GtkCssPaletteValue: 29
GtkCssImageValue: 2765
GtkCssColorValue: 1452
GtkCssFilterValue: 3
GtkCssRgbaValue: 1092
GtkCssShadowValue: 708
GtkCssEaseValue: 33
GtkCssBorderValue: 2
GtkCssTransformValue: 11
GtkCssDimensionValue: 882
GtkCssShadowsValue: 584
SUM: 8428
and after:
GtkCssColorValue: 1452
GtkCssFilterValue: 3
GtkCssRgbaValue: 1092
GtkCssShadowValue: 708
GtkCssEaseValue: 33
GtkCssBorderValue: 2
GtkCssTransformValue: 11
GtkCssDimensionValue: 882
GtkCssShadowsValue: 584
GtkCssBgSizeValue: 23
GtkCssIdentValue: 25
GtkCssPositionValue: 81
GtkCssArrayValue: 143
GtkCssStringValue: 33
GtkCssPaletteValue: 29
GtkCssImageValue: 2765
SUM: 7872
8428 to 7872 is a 556 reduction (6.5%)
asdf
Selectors like *:disabled or *:link have bad performance
implications, since they cause all styles to be recomputed
when the state of the window changes. Replace these by a
list of the elements that are actually affected.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2380
Instead of expecting a superset matcher, call
gtk_css_selector_match_for_change while walking the tree with the
original matcher. This fixes the handling of :not while determining
changes.
Add a GTK_STYLE_CONTEXT_PRINT_SHOW_CHANGE flag that
tells gtk_style_context_to_string to include the
change values of nodes in the output. This will
help debugging css change tracking.
Touchpad gestures have only a single event sequence. The current
'center' of the gesture is the starting point + accumulated deltas.
Update gtk_gesture_get_bounding_box_center() accordingly.
GtkIMContext get_preedit_string should return cursor position counted
in characters, but cursor_begin here is counted in bytes. This add the
missing conversion.
We use the superset matcher in exactly one place,
so there is no need for the generality of allowing
to ignore different aspects. Just hardcode the one
case we need: ignoring everything except for name,
id and class.
The ANY and matcher was not, in fact, matching any state,
since the list of states was not up-to-date.
The same fix applies to the superset matcher as well.
The tree is optimized for mimizing the decisions, and is built ahead-of-time.
That prevents us from taking advantage of the information in the matcher when
collecting changes.
So, instead do what we used to do for verification: Use the selector tree
for finding the superset matches, then just walk the rulesets to collect
the changes.
Since we are now recomputing the change masks much less frequently, this
slightly less optimized way of computing them is not a problem, and will
let us compute better results in the future, by improving the superset
matcher to be more precise.
Most of the time when styles need to be recreated, the name and classes
of the css node haven't changed. In this case, the change value will not
change either, since we are computing change under the assumption that
name and classes are unchanged.
So don't recompute the change. This avoids the second match we do to
find the superset, cutting down the number of times we consult the
selector tree.
The idea is that this reduce the amount of frequently
changing state that css nodes are sensitive to.
This is going to reduce the amount of style recomputation.
