Use the new map/unmap image upload method for Cairo node drawing:
1. map() the memory
2. create an image surface or that memory
3. draw to that image surface
4. success
There's no longer a need for Cairo to allocate image memory.
As an alternative to gsk_vulkan_image_new_from_data() that
takes a given data and creates an image from it, add a 3 step process:
gsk_vulkan_image_new_for_upload()
gsk_vulkan_image_map_memory()
/* put data into memory */
gsk_vulkan_image_unmap_memory()
The benefit of this approach is that it potentially avoids a copy;
instead of creating a buffer to pass and writing the data into it before
then memcpy()ing it into the image, the data can be written straight
into image memory.
So far, only the staging buffer upload is implemented.
There are also no users, those come in the next commit(s).
The GDK_SEAT_CAPABILITY_TABLET_PAD stood awkwardly out of the
ALL value. Even though it's not a keyboard, its focus has more
resemblance to it, so it should be part of this group together
with keyboards.
We were creating the pad device on wp_tablet_pad.done, but
at that time we do not know what tablet it is associated with,
thus we cannot get appropriate vid/pid/name properties for it.
To get that, we need to wait for the pad to enter a surface,
at that time we do know what tablet it is associated with, so
we can get better information about the device.
There are pads that may plausibly "change" tablet between
one .enter event and the next (e.g. Wacom Express Key Remote),
but this situation is highly unlikely. The pad devices created
are thus persistent until that situation happens.
Problem is GtkFileLauncher is unable to handle all the types of URIs
that are supported by gtk_show_uri(), e.g. help: URIs. GtkUriLauncher
avoids this problem.
Another problem is that GtkUriLauncher is just generally a better choice
for launching URIs, since you don't have to create a GFile in order to
use it. Porting code is slightly simpler.
The documentation still mentions both GtkFileLauncher and GtkUriLauncher
as options, but most people will use whatever the compiler recommends
when it prints the deprecation warning.
When the pointer leaves the window surface, gtk_window_capture_motion
will not be called anymore, so priv->resize_cursor may remain non-NULL
indefinitely without this.
If update_cursor is later called (via gtk_window_maybe_update_cursor) on
a virtual enter notify event (e.g. because the pointer entered a
descendant surface), it would previously re-set the window surface
cursor to priv->resize_cursor, which could result in the wrong cursor
shape being shown for descendant surfaces.
This affected mutter-x11-frames, see
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1557.
One could also say that if the pointer leaves the window surface, it's
trivially not over any window edge.
Add an overlay that shows a11y issues.
For now, this checks for:
- abstract roles being used
- elements without labels
- required attributes
- required context
When nodes are added, nothing was warning us that we need to bump
N_RENDER_NODES.
Make sure that that's no longer necessary by refactoring the code to
remove the define.
This is more expensive, but it finds more cases, and in particular it
catches corner cases like empty nodes or fully clipped nodes that might
otherwise make the kernel throw signals in our direction.
When the GTK_MEDIA env var is set, check at startup that it works, not
only when the first MediaFile is instantiated.
This has the fortunate side effect that it prints help output for
GTK_MEDIA=help at startup, too.
