I've seen valgrind complain about external_only being uninitialized
after the call, when using llvmpipe. Better be safe than sorry, and
initialize these arrays.
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.
Previously it was unclear why passing an input stream would crash a video,
unless you went into the source and read it.
This adds a clarifying message that only file based media files are supported.
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
Doing otherwise risks that the focus is moved back to the entry,
causing everything to be selected, and then replaced by the Emoji
we insert. Which is not the desired effect!
When picking a cursor image size for a given size, look for sizes
that do better when scaled by the viewporter:
- exact size
- twice the size
- closest larger size
- closest size
This was a thinko in 403da9a2d5. We have the cursor
image in device pixels, but we still need to apply the viewporter
to inform the compositor about the desired pointer size in
application pixels.
Stop using a viewporter to scale cursors. Instead, just pass
the surface scale to the cursor loading code, and take the
buffer dimensions and hotspot that it returns, unchanged.
This avoids problems with cursor themes like Breeze, where
buffer dimensions are different from the nominal cursor size.
Make the cursor loading code take a floating point scale,
and return the closest sized cursor that it can find.
This resolves issue with labels of model buttons being set to
presentation a11y role but still have a11y label.
See: b7e5a79468/gtk/gtkmodelbutton.c (L1539)
It works, now and is faster than the old GL downloader.
Playing the Barbie trailer @ 4k with hardware decoding but the Cairo
renderer on a 4k screen:
downloader windowed fullscreen
GL 12fps 19fps
NGL 16fps 29fps
Vulkan 16fps 29fps
no dmabufs 12fps 19fps
For some formats, we could not download the dmabuf directly - in
particular YUV formats.
For those, do a copy on the GPU into the correct format.
While we're at it, also check the desired format and colorstate and if
they don't match, do the conversion on the GPU instead of using
gdk_memory_convert().
Reserve the CPU conversion for situations where the GPU doesn't support
the final format - like for example G8A8 (or often also RGB16).
Make gsk_gpu_cache_cache_texture_image() API safer by accepting all
color states as input and just not caching the images for colorstates we
don't care about.
Instead of passing down the depth and extracting format/srgb from it at
the end, extract format/srgb in the nodeprocessor and pass it down.
This allows creating offscreens for weirder formats in the future.
... and use it for the dmabuf downloader
Splits the download op into 2 separate ops: One for downloading textures
and one for downloading into preallocated memory.
The download into memory is the fallback for the texture downloading op,
so they need to share code.
But keeping them separate ensures that the different codepaths for
dmabuf download and render_texture() don't get mixed up in weird ways
that potentially call into each other.
By passing the emory down into the op we can also avoid an extra memcpy
which can lead to quite large speedups for big textures.
We want to share the texture download function with the renderers, so
they can download textures without needing to wrap them in a
GdkGLTexture.
Move it into gdkglcontext.c for that purpose.
