Traditionally the icon lookup for a theme has been:
lookup (icon_name, size):
best_directory = NULL
forearch theme
foreach directory in theme
if dir_size_matches (directory, size) && dir_has_icon (directory, icon-name)
best_directory = chose_best_size_dir (best_directory, directory)
if best_directory
return icon from best_directory
However, it turns out that there are a lot of subdirectories which have the same
size, as they differ only in the (essentially useless) "context" value. For example
the "16x16/apps" subdirectory is essentially the same as the "16x16/actions" one.
So, instead rathern than keeping all the directories as separate we store the
all the directories with the same size as a single entity (DirSize) and the
icon lookup in that DirSize looks up not only which suffix to use for that icon
but also which subdir it is in.
Additionally we keep a hashtable with all icon names that are
available in the entire theme (i.e. all DirSizes), which allows use
both to store each icon name only once, but also to do a quick
negative lookup and early exit in case we're looking up an icon that
doesn't exist. This is pretty common because we often look up sets of
icons like "image-png-symbolic", "image-png", "image", expecting some
to fail.
This brings down the time of the initial css validation from 20msec to 15msec for
me when running icon-factory.
This lists the icons in a particular director, with their flags in a
hashtable. We also convert from "icon.symbolic" + SUFFIX_PNG to
"icon" + SUFFIX_SYMBOLIC_PNG.
We only have implementations of this on X11 and Win32,
so make it available as backend api there.
Update all callers to use either the backend api, or
just monitor 0.
Instead of requiring sassc to be installed add meson subprojects
which build libsass and sassc (currently both forks of mine, tested
under linux/mingw/msvc) when needed.
This allows us to drop the generated .css files and build scripts from git.
See #1502
In gtk_icon_theme_get_for_display() we were calling
gtk_icon_theme_set_display() which eventually (via the css machinery)
called back into gtk_icon_theme_get_for_display() which created a
second icon theme. We avoid this by setting the user-data earlier so
that the css machinery gets back the currently initializing theme
instead.
We look at whether a widget will be mapped (the actual state is not
yet set, so we can't rely on that at css validation time) and use
that to set the i/o priority of the async task.
This means that its likely that widgets that will be displayed soon
are loaded before those that are not yet going to be needed.
This limits the amount of preloading we to, which can for instance
avoid trashing if the icon cache is full, and in general do less work
when its likely to be wasted such as when e.g. background-color for an
icon helper changes.
At the end of GtkImage css validation (during style-updated) when the
css properties (like the icon size) are valid we call _gtk_icon_helper_preload
which does an async icon theme lookup and load. This will happen on a thread
in parallel with the rest of the css machinery, and hopefully by the
time we need the icon it will be ready. If not we will block when we need
it, but during that blocking all the other icons will be loaded.
Testing widget-factory this changes the time of snapshot() from 31 to
25 msec, but on the other hand we also load a few more icons that we
didn't before causing the css validation phase to be about 8 msec slower.
This is because we're preloading all the images in the window, not only
the ones that are visible.
Unfortunately we still load a bunch of icons in snapshot(), from
GtkCssImageIconTheme, and ideally we should try to preload those also.
This happens when we first get the theme for a display, or then the
icon theme setting changes.
This means we don't have to do this scan in the first snapshot
and can do the i/o it in parallel with other stuff. This moves
a 10msec block from the first snapshot cycle to early setup.
If some other thread is lock the icon or icon theme locks they are likely
to do so for a long time, doing i/o. So, switch to trylock() for the
nonblocking part of _async(). This way we can return directly if the
result is available, but do a thread otherwise, never blocking the
calling (main) thread.
Move the lru cache under the global cache lock to avoid some ABBA
style deadlocks when going from icon_theme->icon lock an icon->icon_theme.
We also move all the icon lock uses to a small part of code and make
sure that code never calls out or blocks with any locks held.
Rename the GtkIcon->cache_lock to texture_lock to avoid confusion withe
the global cache_lock.
Removed any mentions of threadsafety from the API docs, we don't
want apps to rely on this, but rather use it outselves internally.
This name can show up in error messages or profiler
traces, so it is nice to provide some hint what
file we are dealing with.
<GtkFileChoser template> is a lot more helpful
than <input>.
This was added in 0b1c9b7cc2 to protect
against reentrancy from the theme-changed signal, but we only emit this
from an idle these days, so thats not necessary anymore, and the recursion
check was causing issues with the async operations where a different
thread loading the theme caused the calling thread to thing the
theme is valid.
This makes GtkIconInfo directly implement paintable by loading
the icon as needed. This is done in a blocking fashion for now, but
could be made more async in the future.
It also means we can't return errors to the called, but I doubt
anyone actually does anything useful with them other than showing
nothing (which we already do).
This also changes a fringe behaviour for unthemed icons. They used to
be never scaled down, but that means we can't tell without i/o the
size of the paintable. Since this is the only case we can't know the
size i took an executive decision and removed that behaviour. I don't
think picking some arbitrary much larger than requested size is ever
right, nor do i think using GtkIconTheme with unthemed icons is overly
useful. If you want to display some random non-iconish image, use
GtkImage instead.
Replace uses of gtk_css_style_get_value with direct access,
throughout the tree. We don't replace all uses, just those
where we are dealing with a fixed property. Be careful to
handle the currentColor special case for color properties.
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.
Add GtkWidget API for adding and removing style classes, as well as
checking whether a widget has a style class applied.
Everyone has to go through GtkStyleContext for this these days but with
GtkStyleContext eventually going away, it makse sense for GtkWidget to
have API for this.
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.
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.
This was a good idea back in GTK3 when popovers were toplevels, but now
they're regular child widgets, so they should behave that way.
Also, with the introduction of the bloom filter, gtk_css_node_validate()
now assumes it's only called on root nodes, so assert that that is the
case.
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.
The FileChooser ToolKit (fctk) had its own machinery to handle default
sizes which was completely busted and trying to marshal random numbers
through the widget hierarchy that maybe made sense in 2012 but don't do
now.
Get rid of it, just keep the dialog's GSetting - which funnily enough
used to be written by the dialog but written by the widget.
But that's fctk for you.
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.
This is not meant to be a full GtkCalendar conversion to use widgets
instead of custom drawing, but we lost the arrows in the calendar header
when builtin icons were removed. Using proper button for the year/month
buttons brings them back.
Use the new gtk_css_dimension_value_is_zero() to check if we really need
to e.g. apply a border radius at all.
We compute css boxes a lot so this makes sense here, it especially shows
up during pick(), where we need the border box.
