| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
The function is used in multiple places, so split it out. In particular
because I'm about to change it.
|
|
|
|
|
| |
_gtk_css_keyframes_compute() returns a reference to a GtkCssKeyframes,
and _gtk_css_animation_new() takes another reference.
|
|
|
|
|
|
|
| |
... instead of from the intrinsic value. This way, we respect running
animations.
Note that the concept of "reversing" transitions is not implemented yet.
|
|
|
|
| |
Instead, query the intrinsic value at runtime.
|
|
|
|
| |
Otherwise we end up with the wrong section if no new one is specified.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
While regular animations should always be created, transitions should
not. This patch allows to express this by passing NULL as the values to
transition from.
It also adds a gtk_style_context_should_create_transitions() function
that returns TRUE when transitions should be created.
|
| |
|
| |
|
|
|
|
|
| |
The code is not needed anymore. And it looked wrong, too, so I'm glad
it's gone.
|
|
|
|
|
| |
Instead of letting the animation set a bitmask unconditionally, actually
compare the before and after values for changes.
|
|
|
|
|
| |
Merge the animated values code into the computed values code. This
should get rid of various bugs related to animated->computed updating.
|
|
|
|
|
| |
It's not used yet, but that will come in the next patch(es). This is a
separate patch to make sure we didn't mess up anything.
|
| |
|
|
|
|
| |
This simplifies the code.
|
|
|
|
|
| |
We now track what values have dependencies on what other values so that
we could in theory recompute them when we need to.
|
|
|
|
|
|
|
|
|
| |
When values are computed, they might depend on various other values and
we need to track this so we can update the values when those other
values change. This is the first step in making that happen.
This patch does not do any dependency tracking at all, instead it uses
GTK_CSS_DEPENDS_ON_EVERYTHING as a sort of FIXME.
|
|
|
|
|
| |
... to the compute vfunc. Simplifies code quite a bit. But makes the
code no longer a simple step-by-step implementation of the spec.
|
|
|
|
|
|
|
| |
Both _gtk_css_style_property_print_value() and
_gtk_css_style_property_compute_value() aren't necessary anymore and are
replaced by _gtk_css_value_print() and _gtk_css_value_comptue()
respectively.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is only a small performance boost by itself, but it's necessary
for animations, so we need it.
Benchmark numbers for my Glade benchmark for interested people:
GTK 3.4.0 last commit this commit
Raleigh
real 0m41.879s 0m10.176s 0m9.900s
user 0m41.394s 0m9.895s 0m9.628s
sys 0m0.111s 0m0.096s 0m0.102s
Adwaita (*)
real 0m51.049s 0m13.432s 0m14.848s 0m12.253s
user 0m50.487s 0m13.034s 0m13.218s 0m11.927s
sys 0m0.117s 0m0.151s 0m0.147s 0m0.107s
Ambiance (patched to not use private GTK APIs)
real 0m52.167s 0m13.115s 0m13.117s 0m12.944s
user 0m51.576s 0m12.739s 0m12.768s 0m12.651s
sys 0m0.119s 0m0.137s 0m0.136s 0m0.118s
(*) Adwaita and unico currently use custom properties, and
_gtk_css_value_compare() for custom properties always returns FALSE,
which makes this optimization never trigger. So I modified
_gtk_css_value_compare() to return TRUE for these properties instead and
reran the benchmark. Those are the numbers.
|
| |
|
|
|
|
|
| |
Now that we use an enum for the IDs, we don't need that function
anymore.
|
|
|
|
| |
Take the property id instead of the name.
|
|
|
|
| |
Also split out initial/inherit handling into a custom GtkCssValue class.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This is useful when overriding values.
|
|
|
|
|
| |
GValueArray is deprecated in glib. Also, bump the required glib version
for g_array_set_clear_func().
|
|
To be used for storing computed values. Is the replacement for
GtkStyleProperties, which is now legacy code.
|