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
Some of these test cases involve :not, and thus are affected
by our now correct handling of it for change computation.
All of them are affected by the window now being visible.
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 various tests for the change flag computation that
we do in the css selector tree.
test1: Just test the basic machinery of this test
test2: Trigger every change flag at least once
test3: Test that multiple states combine as expected
test4: Test negations (known to produce wrong results)
test5: Test a complex selector (not producing the expected
output atm)
widget-factory.ui:
The real thing: widget-factory+Adwaita. Note that
this expedts to be run with GSETTINGS_BACKEND=memory
Note that test4 checks the wrong results that we currently
produce for selectors involving :not. It will have to be
updated when we fix the handling of :not. The widget-factory.ui
testcase will certainly also be affected.
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.
This is a neverending story. I was seeing problems in tests where
the nested mainloop was picking up unrelated timeouts.
Break down and make this async. This changes the ordering in which
the (de)serializers are registered. If this is causing issues, we
can introduce priorities or something else.
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.
