Copy what gcc's libstdc++ does for vectors to avoid overflows:
1. Define a max size macro and assert against it
Note that we don't assert but actually check, because this needs
to abort even if assertions are disabled.
2. Don't do fancy math to compute new capacity.
Just size *= 2 instead and be careful about overflow.
We want to store some metadata in our symbolic pngs, so make it
possible to get options when loading a png, along with the texture.
Update all callers.
Rename things so they make more sense. The dest/source naming got
a bit unclear when we added background into the mix. Now we're going
for:
source_rect - the texture region to display
texture_rect - dimensions of the subsurface showing the texture
background_rect - dimensions of the background subsurface
bounds - union of texture_rect and background_rect
Also use this opportunity to add some api docs.
Make it possible for subsurfaces to have a black background on a
secondary subsurface below the actual subsurface. Using a single-pixel
buffer for that background increases the changes that the compositor
will use direct scanout for the actual subsurface.
This changes the private subsurface API. All callers have been
updated to pass an empty background rect.
Allow to specify a D₂ transform when attaching a texture to a
subsurface, to handle flipped and rotated content. The Wayland
implementation handles these transforms by setting a buffer
transform on the subsurface.
All callers have been updated to pass GDK_TEXTURE_TRANSFORM_NORMAL.
It includes a fallback list of fourccs. Otherwise we might miss some
DRM_FORMAT definition.
This happens in SLES12:
```
../testsuite/gdk/dmabufformats.c: In function ‘test_dmabuf_formats_basic’:
../testsuite/gdk/dmabufformats.c:29:56: error: ‘DRM_FORMAT_ABGR16161616F’ undeclared (first use in this function); did you mean ‘DRM_FORMAT_ABGR2101010’?
29 | g_assert_true (gdk_dmabuf_formats_contains (formats, DRM_FORMAT_ABGR16161616F, DRM_FORMAT_MOD_LINEAR));
```
This will let us use a subset of the full texture, which can
be necessary in the case that converters put padding around
content in dmabufs. The naming follows the Wayland viewporter
spec.
For now, make all callers pass the full texture rect.
The dmabuf texture tests are failing, so we don't run them in
ci, but the format tests are perfectly fine, so split them off.
Add some tests for GdkDmabufFormatsBuilder and for the new
gdk_dmabuf_formats_equal(), too.
The Vulkan renderer can just be public API, because it doesn't expose
any Vulkan-specific APIs.
And it can just exist when compiled without Vulkan, because it can fail
to realize.
Also move get rid of the gsk/vulkan/gskvulkanrenderer.h header. It was
experimental and isn't necessary now that the renderer is included via
gsk.h.
gdk_texture_save_to_png_bytes() cannot fail, so ensure that it doesn't.
Testsuite has been updated to check for this case.
Note that we do not load the PNG file that we generate here.
Loading is a lot more scary than saving after all.
If people want to load oversized PNG files, they should use a real PNG
loader.
We want to introduce a new one next.
Technically, this breaks API, because gsk_vulkan_renderer_new() is going
away, but practically, we're gonna bring it back once we introduce that
renderer in a few commits.
We did have 4 ordering variations of ARGB straight,
but only 3 premultiplied. Add the missing one.
Update all the places where we switch over memory formats.
The relevant question here is about details, because we have to choose
if we declare alpha-only formats as having their (nonexistant) color
channels premultiplied or not, so that the code paths using them can do
the right thing.
Because we are premultiplied by default, it makes sense to treat alpha
like that, because then the alpha-only code doesn't need to do
workarounds for straight alpha.
Where this is relevant of course is when expanding the alpha channel
into color channels, where we want to end up with white.
So make sure we do color = alpha there instead of color = 1 like we did
before.
We need them for mask-only textures.
For tiffs, we convert the formats to RGBA (the idea that tiff can save
everything needs to be buried I guess) as tiffs can't do alpha-only.
When running the tests, only run the random (and potentially large) size
download test once instead of 10 times.
There's no real benefit in doing that, both because it's unlikely to
fail only in the 2nd or 9th run and because the sizes are picked
randomly.
This also speeds up the test massively as the download test was
dominating the runtime.
Instead of picking a few numbers in advance and running them through the
test gauntlet every time, pick the random numbers at runtime.
This both increases the test coverage in that it ultimately tests more
combinations across many runs and it reduces the runtime of individual
runs because every tun only runs the download tests twice (with 1px and
the random size) instead of 5 times.
And that speedup benefits the CI, where the asan runs would cause this
test to timeout sometimes.
Add some odd-sized texture sizes to the
download tests, to trigger alignment issues
in the various upload code paths. And add
a size that is bigger than the max-texture-size
we force in one of our test setups.
To compensate, reduce the number of
runs per size from 20 to 10.
