Depth of a rendernode should be determined by the textures used and the
compositing colorstate requirements.
Colors influence the colorstate choice, so they indirectly influence the
depth, but they should not influence the depth directly.
Otherwise a single color in a border being rec2100-pq would make us
switch to 16bit float.
Also remove gdk_color_get_depth(), because it was only used here and
because again: Colors should not influence depth decisions.
We want to use the display's context on the resulting texture,
but we do not want to use it for the stufff we need to do while
exporting - most importantly the GLsync.
Fixes#6976
It seems we can get spurious de-registrations, so let's avoid spamming
the logs, and also avoid crashes from applications whose maintainer
decided to turn all critical warnings into assertions.
Previously it ended on the immediate parent of the lowest level popover,
which was not good, as it very likely was some even already hidden widget, or
at least, the a11y machinery thought so.
When selecting an emoji in the recent section, there is no need
to add it to the recent section again. This avoids a sequence of
unfortunate events, where we reconstruct the entire recent section,
thereby removing the focus child, causing the focus to revert to
the entry, causing the entry to select the entire text. In the
case of Ctrl-clicking to select multiple Emoji, the effect is that
the section Emoji will replace the entire entry text, which is
suprising and unintended.
Fixes: #6336
When prepare_gl fails in the right way (or the wrong way?), we
end up creating the leader window twice, and as a side effect,
creating two instances of the "Virtual core pointer" device, which
is bad news for grabs.
Fixes: #6840
Call wl_surface_offset in end_frame to apply the offset for drag
surfaces. This matches what the GL draw context already does, and
it fixes drag surfaces jumping at the beginning of the drag.
Fixes: #6972
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 function is used to sort a GPtrArray of "pointers" which are
actually GINT_TO_POINTER (id), so a and b are pointers to pointer-sized
quantities.
Previously it was assuming that both were int-sized quantities,
dereferencing them to get the first sizeof(int) bytes, and then
redundantly casting those bytes to int. However, on a 64-bit big-endian
platform, the first few bytes of a larger-than-int quantity are the
most significant part, in practice 0, causing an out-of-bounds array
access and a crash. This was visible in the
`gtk:css / parser variables.css` automated test.
Bug-Debian: https://bugs.debian.org/1079546
Signed-off-by: Simon McVittie <smcv@debian.org>
Previously this code assumed that if we have an int stored in a hash
table via GINT_TO_POINTER, we can retrieve the pointer value and treat
its first sizeof(int) bytes as an item to append to a GArray of int.
However, on a 64-bit big-endian system, the first sizeof(int)
bytes of the pointer will be zero, which is not a valid ID for a
GtkCssCustomPropertyPool, causing an out-of-bounds array access and
a crash. This was visible in the `gtk:css / style` automated test.
Bug-Debian: https://bugs.debian.org/1079546
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.
