We may try to update the XRR outputs and Crtcs when they're changing in
the server, and so we may get BadRROutput that we're currently not
handling properly.
As per this, use traps and check whether we got errors, and if we did
let's ignore the current output.
It's not required to call init_randr13() again because if we got errors
it's very likely that there's a change coming that will be notified at
next iteration during which we'll repeat the init actions.
When registering an observer, we send a notification and for that we need
to query the action's state and param type. When setting up a muxer parent,
same thing happens, except the action is queried on the parent instead.
This means that the muxer will notify observers about the parent's actions,
but not about its own.
Add a test to verify it works.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5861
This is not the optimal way of doing it: we're
reuploading the texture with client-side conversion.
But it fits nicely into our current handling of mipmaps.
We can do better once we use shaders for colorspace
conversions.
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.
For non-gles, make it handle unpremultiplied formats,
and everything else, by downloading the texture in its
preferred format and, in most cases, doing a
gdk_memory_convert afterwards.
For gles, keep using glReadPixels, but handle cases
where the gl read format doesn't match the texture
format by doing the necessary swizzling before calling
gdk_memory_convert.
Make the callers of this function check for
straight alpha themselves, and only do the
version compatibility check here. This makes
the function usable in contexts where straight
alpha is acceptable.
Use &__ImageBase for the GTK DLL and GetModuleHandle (NULL)
for the application module. Then remove DllMain as it's not
necessary anymore.
References:
[1] Accessing the current module's HINSTANCE from a static library:
https://devblogs.microsoft.com/oldnewthing/20041025-00/?p=37483
The display xevent signal connection takes the ownership of the stream
until we get a valid event, so it should manage the stream lifetime.
So make this clearer, by automatically removing the stream reference
when we disconnect from the xevent signal handler.
We create a new stream during gdk_x11_selection_input_stream_new_async()
then such stream is referenced when passed to the task via
g_task_return_pointer(), so there's no need to reference it again before
returning it, or we'd end up leaking.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4892
