The notable exception here are the global provider apis,
which are needed in some form and don't have a replacement
yet. Move them to gtkstyleprovider.[hc], so we can wholly
deprecated gtkstylecontext.[hc].
If set to TRUE, does not call the free func for the removed items.
This can be used to move items between arrays without having to do the
refcounting dance.
This is used for widgets that contain the focus widget,
reserving the focused state for the focus location itself.
This aligns our focus state handling with
https://www.w3.org/TR/selectors-4/
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.
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.
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.
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.
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.
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.
This commit is still way too big, but I couldn't make it smaller.
It transitions the old CSS parser to the new parser. CSS parsing is now
tokenized, everything else is probably still buggy.
We can't try to get an integer because ultimately integer getters
support the same shenanigans that numbers and percentages do with calc()
and whatnot.
