This is an unused feature that's way too complicated for a default
calendar widget and complicates the implementation a lot. Since we want
to eventually replace this with actual widgets, remove the details
support now.
These will replace the previous gtk_snapshot_new_with_parent(), which
allocated an entirely new GObject just to push()/pop() some state. This
is already a problem but will be more important in the future as we
start using this more.
When reaching this point, it is impossible that all border styles are
HIDDEN or NONE, but up to 3 of them can still be that style. In any
case, the "none or solid" border style is the most common on there is,
so try to make this simpler here by just appending a border node
directly instead of going through the snapshot_border path.
Hide the expensive GTK_IS_ROOT() checks behind the cheaper realized,
mapped, etc. checks. This way we only check for the widget being a root
if the invariant does not hold.
This gets pop_verify_invariants() from 16% to 6% when running the
scrolling benchmark in the widget-factory.
When the css is validated we know the css size, so we can
create the paintable at that point, and we do so passing the
LOAD_IN_THREAD flag.
This causes us to load most icons early on, in parallel instead of
during the first snapshot.
Instead of having the IconTheme have a hashtable that owns
individual strings and then IconThemeDirSize have a similar
hash (but with the strings owned by the other hash), we
have a consecutive memory chunks where we store the icon names
and then the hashtable has pointers into this.
This means we can avoid a bunch of individual strdup()s in a
way that is less fragmented and wastes less space. Additionally,
since we do an initial lookup anyway we have the internalized
icon name during lookup which means we can use g_direct_hash/equal
instead of g_str_hash/equal making the lookup faster too.
If there is a passive grab and the pointer leaves the window we would
receive a GDK_CROSSING_NORMAL event when the pointer moves outside
the window, and a GDK_CROSSING_UNGRAB event when we do release the
button and the implicit grab.
We currently would react to the first, but want to react to the
second. In the time between both events, the client would still receive
pointer motion that will reach the implicitly grabbed widget.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/13
