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 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.
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.
This is just lots of renaming.
The interface remains private, so the public API does not change, apart
from removing the definition of the Interface object to avoid
subclassing.
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.
For now, this is only an implementation detail of the animated style.
The idea is to use GtkCssStaticStyle as the result of CSS queries and
then put a GtkCssAnimatedStyle on top that manages the animations. The
neat thing about this is that you can cache the static values.