This fixes monitor enter and leave events on X11, and probably other
things. Previously, it looks like the coordinates were relative to the
top left corner of the window shadow and so never changed.
Whether or not switches include shapes to indicate their ON/OFF
state is currently controlled by the stylesheet (in particular
the HighContrast style).
However there are use cases for both using the HighContrast style
without shapes, and for using shapes with the regular stylesheet,
so follow the newly added "show-status-shapes" setting instead.
https://gitlab.gnome.org/GNOME/gtk/-/issues/5354
It started out as busywork, but it does many separate things. If I could
start over, I'd take them apart into multiple commits:
1. Remove G_ENABLE_DEBUG around GDK_DEBUG_*() calls
This is not needed at all, the calls themselves take care of it.
2. Remove G_ENABLE_DEBUG around profiling code
This now enables profiling support in release builds.
3. Stop poking _gdk_debug_flags and use GDK_DEBUG_CHECK()
This was old code that was never updated.
4. Make !G_ENABLE_DEBUG turn off GDK_DEBUG_CHECK()
The code used to
#define GDK_DEBUG_CHECK(...) false
#define GDK_DEBUG(...)
which would compile away all the code inside those macros. This
means a lot of variable definitions and debug utility functions
would suddenly no longer be used and cause compiler errors.
This is implemented using a new xdg_toplevel `suspended` state, and is
meant for allowing applications to know when they can stop doing
unnecessary work and thus save power.
In the other backends, the `suspended` state is set at the same time as
`minimized` as it's the closest there is to traditional windowing
systems.
Sometimes, GLX can decide to use the previous request serial when faking
XErrors via __glXSendError() (look through the Mesa sources to enjoy).
This can cause the error trap we just installed to not feel responsible
for the error. And that makes GDK decide to immediately abort the
application.
That is not what we or GLX want.
So we use a no-op X Request to bump the request number so that when GLX
does its shenanigans, it uses a serial that our error trap will catch.
Fixes a crash in mutter's CI which apparently manages to drive GLX
without an X server.
In error cases, glXCreateContextAttribsARB() will always return NULL so
it is enough to run the loop until the first non-NULL context is
returned.
And at that point, we can just look at the return value and ignore all
errors.
Instead of trapping errors for the whole loop trying to create GL
contexts, trap them once per GL context.
Apparently GLX does throw an error when a too high version is requested
and doesn't just return NULL and then that error lingers when we try
lower versions.
Fixes#5857
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.
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
XWayland (at least on gnome-shell) does not support SGI_swap_control,
which we were using to unset the swap interval.
It does support EXT_swap_control though, which is the more modern
version of the same thing, so this commit adds support for that.
And now GDK_DEBUG=no-vsync gives me >1000fps instead of just 60fps,
The Expose events following a ConfigureNotify may arrive at
a time that we did not resize the surface yet, making these
expose events a no-op. Even though gsk/gtk take care of the
window content itself, this might lead to unrendered portions
of the window shadow.
This may be seen with GSK_RENDERER=cairo and GDK_BACKEND=x11,
attempting to tile a window (e.g. gtk4-demo) left or right.
The window will show black rectangles or other artifacts in
the window shadow areas that correspond to the newly painted
portions (as the window needs to expand vertically).
In order to fix this with a similar behavior to Wayland,
consider ourselves the whole surface invalidated after resize,
in order to ensure everything is painted from scratch.
GLES 2.0 version is fine now with current gtk according to B. Otte.
Let's use the same minimum requirement for all implementations.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
