Benjamin Otte [Sat, 7 Apr 2012 16:09:17 +0000 (18:09 +0200)]
stylecontext: Compute if things changed before invalidating
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.
Benjamin Otte [Sat, 7 Apr 2012 12:15:35 +0000 (14:15 +0200)]
widget: Don't cache widget paths all the time
Add an internal API that allows GtkStyleContext to create a widget path
for the widget and with that bypassing gtk_widget_get_path() and that
function caching the path.
Benjamin Otte [Sat, 7 Apr 2012 05:40:36 +0000 (07:40 +0200)]
cssvalue: Split out old value handling to new typed value
... and Make this new value be a real GValue, as we don't need to save
performance for these anymore (it's just used for custom properties).
And I'd rather have code work for all values then be optimized for no
reason.
Benjamin Otte [Tue, 3 Apr 2012 17:11:41 +0000 (19:11 +0200)]
cssstyleproperty: Convert binding sets
Instead of keeping a custom GPtrArray, keep it as a GtkCssArrayValue of
GtkCssStringValue. This way, we gain equality comparisons and print
functions for free.
Benjamin Otte [Tue, 3 Apr 2012 09:49:46 +0000 (11:49 +0200)]
cssvalue: Make GtkCssShadowValue only hold one shadow
All the properties now are a GtkCssArrayValue of GtkCssSadowValue.
GtkCssArrayValue already does everything we want, so no need to
duplicate its funtionality.
Benjamin Otte [Mon, 2 Apr 2012 21:28:37 +0000 (23:28 +0200)]
stylecontext: Don't queue_resize() all the time
When a parent style context exists, there's no need to queue_resize() on
the widget, because the parent widget will call
gtk_style_context_validate() on us and _then_ we can call queue_resize()
if we have to.
Benjamin Otte [Mon, 2 Apr 2012 07:16:08 +0000 (09:16 +0200)]
cssstyleproperty: Mark all animatable properties
Only the ones that can be animated are marked of course. So more work is
needed.
This is important for
transition-property: all;
because it'll just animate all the properties that can be.
Benjamin Otte [Sat, 31 Mar 2012 03:28:58 +0000 (05:28 +0200)]
css: Add an enum for all the style properties
So instead of using
_gtk_css_style_property_get_id (GTK_CSS_STYLE_PROPERTY
(_gtk_style_property_lookup ("name")))
one can now use
GTK_CSS_PROPERTY_NAME
Benjamin Otte [Wed, 28 Mar 2012 04:28:13 +0000 (06:28 +0200)]
cssvalue: Add a custom RGBA value
Note: custom CSS properties still use the default GtkCssValue and always
will.
So there is a difference in css values used between those, even though
they both carry a GdkRGBA payload.
Benjamin Otte [Tue, 27 Mar 2012 05:51:20 +0000 (07:51 +0200)]
styleproperty: Simplify compute_value function
The compute_value fallback path is only needed for custom properties,
the real style properties have custom compute functions if they need
them already.
Benjamin Otte [Tue, 27 Mar 2012 03:11:58 +0000 (05:11 +0200)]
stylepropertyimpl: Add color parsing function
This is in preparation for removing the specified type and computed type
properties from GtkCssStyleProperty, which is in preparation for really
using GtkCssValue classes and not GTypes.
Benjamin Otte [Mon, 26 Mar 2012 23:43:12 +0000 (01:43 +0200)]
cssvalue: Add _gtk_css_value_equal()
For now, we return FALSE for all default css values, so this is not very
useful.
I also think of this as an optimization equal, not a guaranteed equal,
because we don't even have a notion of what "equal" means.
For example, for background-repeat, "repeat, repeat" and "repeat"
are functionally equivalent. But the cssvalue has no idea that it's used
for background-repeat.
As a more complicated example, "repeat, no-repeat" and "repeat" are
equal to what one sees as long as there's only one image listed
background-image-source. But once you start transition'ing to an image
with 2 sources, it's different...