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.
The GL renderers like to premultiply content that isn't, and due to the
data loss with alpha == 0 (transparent white, transparent black and
transparent anything are all represented by (0, 0, 0, 0) when
premultiplied) these values cannot be converted back.
There is no longer a need to use gdk_texture_download() and force
conversion to ARGB8 format. We can download the pixels in the original
format again.
That way we avoid testing the conversion code and avoid having to deal
with differences in representable colors.
However, some formats do do conversions, so we allow pixel comparisons
to be accurate (requires 16bit comparison accuracy) or inaccurate (we
only care about 8bit).
Note that for the default RGBA formats, this is identical and means they
need to be bit-exact the same, no matter what.
But the higher bit depth formats may be more different - floating point
can even have different values with high accuracy (the float mantissa is
23 bit, we only care about 16).
That way we ensure that the GL context(s) get disposed, which they
previously weren't due to them still being the current context.
This also implicitly adds testing of gLContext destruction, which
previously wasn't ever done by any test.
Use a GL renderer to upload textures (and then optionally download them
via release() again). This way, we can test that the GL renderer
properly uploads textures to the right formats (not losing information
for HDR for example) and downloads them again.
This is the default OpenGL format, and in fact the only pixel format
that GLES supports uploading as. Actually, the premultiplied part is
really just about how we use the textures, but all textures in GTK
are premultiplied.
The calls used old bugzilla URLs and nobody cared about that.
So apparently they are very unused.
There's also a potential conflict between gitlab and bugzilla URLs and
what base bug to use there.
The old usages have been converted to comments.
