It seems that Meson's gnome.compile_resources() cannot deal with two
files with the same name under different directories, which breaks the
build parallelism because the GResource file ends up not depending on
either the Adwaita or the HighContrast gtk-contained.css file.
This commit only changes the on-disk names of the Adwaita and
HighContrast SCSS files, and the corresponding generated CSS files; the
files in the GResource are going to be aliased to the old file names, to
minimise the breakage. We might want to change the theme entry points at
some later date, if we decide to commit to this naming scheme.
Fixes: #2423
See Meson bug: https://github.com/mesonbuild/meson/issues/6615
These don't take a duration, instead they call g_get_monotonic_time() to
and subtract the start time for it.
Almost all our calls are like this, and this makes the callsites clearer
and avoids inlining the clock call into the call site.
When we use if (GDK_PROFILER_IS_RUNNING) this means we get an
inlined if (FALSE) when the compiler support is not compiled in, which
gets rid of all the related code completely.
We also expand to G_UNLIKELY(gdk_profiler_is_running ()) in the supported
case which might cause somewhat better code generation.
usec is the scale of the monotonic timer which is where we get almost
all the times from. The only actual source of nsec is the opengl
GPU time (but who knows what the actual resulution of that is).
Changing this to usec allows us to get rid of " * 1000" in a *lot* of
places all over the codebase, which are ugly and confusing.
As pointed out in https://gitlab.gnome.org/GNOME/gtk/issues/1481
and seen from critical warnings with swinging revealers in widget-factory
there are some size allocation issues in GtkRevealer.
What happens is that we request a size of the revealer itself
based on the child natural size and the current stage of the transition
by applying a scale to the natural size. We then round up to nearest
int size. However, we want the widget to render as if it did get the
natural size so we can transform it, rather than the scaled down size.
For example, a label should not start ellipsizing in the animation.
So we inverse the scale when allocating the child.
Unfortunately, for very small scales the inversion of the scale can
result in very large sizes, and for such scales we rounded up the
requested size to 1, so we will be allocating huuuuge children.
In order to avoid such issue we pick an arbitrary maximum upscale
scale factor of 100. This means that in the case where the allocated
size is 1 we never allocate the child at > 100 px. This means
that in large downscaling cases we may run into the clipping issue
described above. However, at these downscaling levels (100 times!)
we're unlikely to notice much detail anyway.
We can't just use the outline rect and apply the border radius because
the outline box is the border box grown by the outline offset, which
will also grow the resulting border radius.
Fixes#2425
We test this by looking at the produced render nodes now that
we don't actualluy scale the icon. Also, it turns out that this
code was broken due to some typos, so we also fix those.
If you called gtk_icon_theme_lookup(), then always return some useful
icon name from gtk_icon_paintable_get_icon_name(), even if we picked
an unthemed icon.
Also rewrite the gtk_icon_paintable_get_icon_name() docs to make this
clearer.
In GTK2, the filechooser was using a Paned, so switching between sidebar
and files list with the arrow keys didn't work (the slider would be
selected instead). So in
https://bugzilla.gnome.org/show_bug.cgi?id=161489 a crude hack was added
to make this possible.
Over the years the filechooser code has changed so that it now would do
this by default, yet the hack had been retained.
These are always set to the same value as the corresponding border
radius properties. They are also non-standard, so remove them and
replace them with the border radius properties everywhere.
Fixes#2414
When we are loading symbolic pngs or svgs, we know
that we need to the png or svg loader, so there is
no need to go through (surprisingly expensive) mime
sniffing to find the right loader.
It doesn't really make sense to treat double clicks here different than
single clicks (and is bad UX), and it also breaks switching months by
quickly trying to single-click the last/first days in the calendar.
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.
