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.
It would probably be better to not do this and always render the outline
in plain white, then later recolor it but do this for no, just for
correctness.
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
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.
