Clip from 1025px (which is what this test is about) to 1024px because the
GLES2 renderer in CI otherwise scales its repeat node offscreen for the
--repeat version of this test and that conveniently produces off-by-one
misrenderings everywhere.
However, we need to keep the image large enough so that all the glyphs
are actually rendered and not skipped which would not overflow the
cache.
This test is specifically engineered to trigger an overflow in the glyph
renderer that was theorized on IRC with an earlier patchset.
If only one slice was available, and that slice was not high enough to
hold the glyph we were trying to put in there, it would allocate a slice
that was too small. The check for the size was missing.
So now add a test that fills up all the slices in the glyph cache apart
from one and than tries to add one final glyph that is too large for the
last slice.
Previously, we only checked if the cache had exhausted the maximum
number of slices.
But we also need to check that the height of the slices doesn't exceed
the height of the texture.
After the node-editor crashed on me once too often, I decided to take a
good hard look at the parsing code and add a bunch of weird corner
cases into the testsuite.
That meant redoing the parser so that the error paths cause neither
crashes nor duplicated or wrong error messages.
This function wasn't needed so far so I didn't add it.
The next commits will use it.
I made has_url() return TRUE for the BAD_URL token, even though a
BAD_URL is not a valid URL. But parsing code will almost always want to
treat these tokesn the same way it would treat otherwise bad urls, so
returning TRUE here makes it go own the right error path in calling
code.
The gl renderer has an optimization where it uses the glyph atlas
to render color nodes that show up in the middle of text (e.g. for
underlines and carets). This adds a simple test for that scenario,
which hits this codepath.
When a toplevel is focused programmatically and there is no
underlying seat, we cannot attempt to focus it with no
focus to be obtained, nor serials serials to use.
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/6335
We can derive whether we are build a developement snapshot or
a stable version from the minor version number. So do that.
This way, we'll get the devel profile selected in the nightly
SDK, which will make the commit sha appear in the inspector,
which is useful to determine what nightly users are testing.
We want to use the same header in the inspector, so move it to
the toplevel. And since it is no longer for demos only, rename
it to profile_conf.h, and also rename the build option back
to profile.
When using g_object_weak_ref(), it is important that you can discover
weather or not it is safe to call g_object_weak_unref(). That is
problematic if you use a naked pointer to structure. Additionally,
if a GWeakRef is used, and things are not cleaned up carefully,
GObject itself will try to write to it. So ensuring that the GWeakRef
is cleared safely before the owning struct is finalized is paramount.
That is difficult if you are unsure wheather or not your weak_ref
callback has been called.
This introduces WeakRefGuard which is an indirection pointer that is
cleared on the first unref. There are only ever two references. When
the owning struct is finalized or the weak ref callback is called, an
unref will occur and the guard will clear the data pointer.
By doing this, we gain the capability to send notifications when their
accessible names change. Also, it simplifies the accessible name
generation logic.
