All the a11y tests were failing for me with a window state diff
like this:
- state: active enabled resizable sensitive showing visible
+ state: enabled resizable sensitive showing visible
I guess the windows in the CI always gets the focus, but not when
I run it here. Generally focus seems asynchronous and hard to rely
on so I just made the test ignore the active state on toplevels.
These days initilizing gtk may create a connection to the sesson bus,
so we have to initialize GTestDBus before initalizing gtk, or we'll
use the address of the "real" session bus (and remember that in the
global).
To further muck things up, g_test_dbus_up() resets important env
vars like DISPLAY and XDG_RUNTIME_DIR, which we have to re-set.
This was blocking the clean exit from the testdbus shutdown in
the defaultvalues test. The proxy was keeping the connection alive
which blocks g_test_dbus_down().
This adds a GDK_DEBUG=default-settings flag which disables reads
from xsettings and Xft resources, and enables this for the testsuite.
This is one less way to get different testresults depending on the
environment. In particular, it was failing the css tests for me
due to getting the wrong font size because i have a different dpi.
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.
