If that flag is set, we keep the bounds of the original node when
rendering the modified node.
Gets around the replay test having to draw a transparent color node to
ensure the same bounds.
Compositors don't guarantee that there's any physical devices
around to correspond to the input capabilities.
This was found running the tests against mutter headless.
The clip might be different from the scissor due to incompatible
intersections.
But the resulting intersection might be fully clipped, so we should
consider it.
Testsuite with longer explanation attached.
Fixes#7044
Due to a Mesa bug, RGBA16 images aren't properly handled sometimes and
can cause random failures.
In this case, generating the modified reference images for the tests
fails.
Fixes CI breakage.
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11750
This takes the `position` property and ensures children are sorted by
it, splits children by `pack-type` (also reversing the order of `end`
children), and handles children with `type="center"`.
If either a center child or end children exist, then the `GtkBox` is
converted to a `GtkCenterBox`, with `start-widget`/`end-widget` being a
nested `GtkBox` with the relevant children.
The splitting does cause some non-`object` children to sort differently
(hence the change to `office-runner.expected`.)
Some nodes like `GtkBox` need to process removed-in-GTK4 attributes to
correctly convert their contents. If the node children are processed
first, then those attributes are removed prematurely.
Opaque textures don't clamp to transparent but instead to black.
We didn't consider this, so we were blurring their edges into blackness
not into transparency.
Fix this by adding the GSK_GPU_AS_IMAGE_SAMPLED_OUT_OF_BOUNDS flag
and respecting it in the implementation that uses it.
Test included.
Fixes#6980
rgba(from @foo ...) would crash if @foo was not a named color.
Handle it as we do elsewhere, by returning NULL from resolve().
Test included.
Fixes: #6985
If all four of the random colours have alpha channel exactly 0.0,
then the computed premultiplied average will also be zero.
Normalize the expected colour to (0,0,0,0) rather than (NaN,NaN,NaN,0).
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/6977
Signed-off-by: Simon McVittie <smcv@debian.org>
On GTK's official upstream CI, all Linux runners are meant to have
/dev/udmabuf available, so this should pass. On developer machines or
downstream build environments, this can't be guaranteed (not all kernel
configurations offer that device, and on those that do, an autobuilder
might not have access to it) so make it possible to skip this with
`--no-suite=needs-udmabuf`.
Any future tests that rely on /dev/udmabuf (as opposed to using it for
optional better coverage if available, like replay-node does) can be
aded to the same suite.
Signed-off-by: Simon McVittie <smcv@debian.org>
This more closely matches the spec. This is an API break, however the
atspi backend already assumed that this was a list, and would throw
criticals whenever this relation was set. Therefore it can be assumed
that this relation was not previously in active use.
This requires adding infrastructure to generate per-test data, so that
the random clip rect can be computed and reused for both test and
reference generation.
So add this infrastructure.
