Symbolic icons use a "-symbolic" suffix to distinguish themselves from
highcolor variants. Note that the dash character here has a different
meaning than the specificity level defined in the icon-naming-spec [1],
as it identifies a property of the icon itself.
Since they might be provided by a parent theme (e.g. the HighContrast theme
relies on the gnome icon theme for them), when we are looking up one we
should first escape the generic icon inheritance mechanism defined in the
icon-naming-spec [1], and privilege a symbolic icon, if it exists in a
parent theme, before applying the inheritance evaluation.
This fixes symbolic icons not working properly when used in the
HighContrast theme with the GTK_ICON_LOOKUP_GENERIC_FALLBACK flag set.
[1]
http://standards.freedesktop.org/icon-naming-spec/latest/ar01s03.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=674806
Avoid doing useless translations/rotations, since themes will most
likely set different CSS gradients using left/right/top/bottom style
classes, or use a plain color.
https://bugzilla.gnome.org/show_bug.cgi?id=674809
This was broken since before GTK+ 3.0, when we replaced
a use of requisition by allocation. Fix this by using the
requisition height, that is already cached by the menu code.
The math is not quite right here; if you page all the way
down a long menu, you end up on the second-to-last menuitem.
But at least, page up/down let you move up and down the menu
again.
https://bugzilla.gnome.org/show_bug.cgi?id=668931
Of course, we must pass coordinates in the NSWindow coordinate system
when creating an NSEvent. This fixes drag icon positioning and makes
the icon slide back to the correct position when the drag is
canceled.
Instead of overriding the font theme settings, just set the Pango
attributes we want on the label. This fixes message dialogs growing on
style_update after recent GTK+ changes.
Instead of using 1 global queue for both resizes and style validation,
use 2 queues. This makes the code a lot simpler and fixes a bug where we
could accidentally stop restylying for very delayed restyles.
We now animate the core style information (see comment in
gtk_style_context_save()). A lot of widgets save + set custom style
classes/states during drawing and so can't be animated. It does work for
labels, menus and buttons though.
This is a GtkCssComputedValues subclass. So it's essentially a store for
computed CSS values. But it can be animated by advancing it to a certain
timestamp.
A StyleAnimation is an immutable object used to track the state of CSS
values. I'd have liked to make it fully immutable - ie not have the
timestamp in there - but couldn't find a place to sanely store the
timestamp.
This is an abstract base class. Implementations for this will be added
later (for both CSS3 transitions and animations, potentially for
animated images).
Actually aplying the information in this object will be done by a
different object commtted later.
This has two goals:
1) Move invalidation code out of a nested if branch. Invalidation is
actually the most important thing this function does.
2) Have the changes bitmask available. It will needed for invalidate
calls to children later.
The design principles were:
- synchronized
If multiple style contexts are animating, they should all do an
animation step at the same time.
- degrades well
Even when there's thousands of style contexts all animating at the same
time, the animation steps don't starve the CPU. This is achieved by
making sure the timeout is really fast. It just sets a bunch of flags.
- no hidden bottlenecks
Turning animatability on or off on a style context is O(1).
So far it is unused.
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.
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.
Instead, look up the variable upon use. This is more correct (for when
the engine changes due to save/restore() shenanigans.
And it removes code that doesn't use the standard code paths.
Equality tests are done with _gtk_css_value_equal(). There is no need to
do it per-property, equal values will still be equal.
This essentially reverts 24f5d54329e028347bd76af42e86ed190c1229a2 and
92c7a7171e1240b6d961ee5b6f9ab6b596e98904.
... 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.
