Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
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.
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.
It's almost never useful to have a bitmask here, since it's only used
for the intersection case in gtk_css_style_provider_lookup. However,
even if that returns true, we still need to check every single style
property for being set again in the look afterwards.
Just remove the bitmask.
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.
The only style that is animated is the style of the unsaved primary
node. So there's no need to create animated style objects for the other
ones.
There is a bunch of ugliness in the code currently. Further commits are
expected to fix them.
GtkCssStyle is the base class to be used for all types of styles that do
exist.
GtkCssAnimatedStyle is the only implementation so far, that is exactly a
copy/paste of the old GtkCssStyle code.
This special code was added back in the days when computation wasn't
idemptotent. These days it is.
Also, the bypass code path is only used in fallback code that is pretty
much unused.
We need to be able to compute different GtkCssImage values
depending on the scale, and we need this at compute time so that
we don't need to read any images other than the scale in used (to
e.g. calculate the image size). GtkStyleProviderPrivate is shared
for all style contexts, so its not right.
Here's the shortest description of the bug I can come up with:
When computing values, we have 3 kinds of dependencies:
(1) other properties ("currentColor" or em values)
(2) inherited properties ("inherit")
(3) generic things from the theme (@keyframes or @define-color)
Previously, we passed the GtkStyleContext as an argument, because it
provided these 3 things using:
(1) _gtk_style_context_peek_property()
(2) _gtk_style_context_peek_property(gtk_style_context_get_parent())
(3) context->priv->cascade
However, this makes it impossible to lookup values other than the ones
accessible via _gtk_style_context_peek_property(). And this is exactly
what we are doing in gtk_style_context_update_cache(). So when the cache
updates encountered case (1), they were looking up the values from the
wrong style data.
So this large patch essentially does nothing but replace the
context argument in all compute functions with new arguments for the 3
cases above:
(1) values
(2) parent_values
(3) provider
We apparently have a lot of computing code.
Also, in places where we're computing a new CssValue based on an
old one, make sure that if nothing changes we're returning a reference
to the old one, rather than creating a new identical instance.
Checking if the value is NULL is the wrong thing to do - the bitmask is
usd to keep track of that.
The reason for that will become apparent in the next patch.
Instead of on-demand resolvage, we now resolve during lookup. The step
is done via
_gtk_css_style_property_compute_value()
which currently calls into
_gtk_css_style_compute_value()
That function has all the old resolving machinery.
The only part missing for now is the handling of win32 code. It will be
added back later.
See inline code comments taken from
http://dev.w3.org/csswg/css3-cascade/#cascade
This now respects the special values "inherit" and "initial" properly.
Note that those values cannot be parsed yet. This will be added in a
future commit.
We now use the GtkStleProviderPrivate interface, which hopefully is
faster and more conformant to CSS. Long term, it definitely should be
both.
I would have liked to split this up into multiple commits, but couldn't
find a way.
