The term "hdr" is so overloaded, we shouldn't use them anywhere, except
from maybe describing all of this work in blog posts and other marketing
materials.
So do renames:
* hdr => high_depth
* request_hdr => prefers_high_depth
This more accurately describes what is going on.
Forces request_hdr = TRUE for all requests.
Backends should also use this when choosing whether to honor HDR
requests for low quality compositors - as long as the compositor
pretends to support HDR, shovel HDR at it.
We have a global GdkGLBackendType now, just set it.
This way, using the variable forces the backend type, and we don't need
special code handling the env vars in the backends.
It also means setting the env var will now "work" on GDK backends that
don't even support that GL backend and simualte another GDK backend
having registered that GL backend already. So you can run
GDK_DEBUG=gl-wgl gtk4-demo
on test what Wayland will do when WGL is in use.
This way, one can force using WGL on Windows even if EGL support was
enabled. Also update the help text for gl-egl as it will apply for
Windows, albeit a bit later.
We try EGL first, but are very picky about what we accept.
If that fails, we try to go with GLX instead.
And if that also fails, we try EGL again, but this time accept anything.
The idea here is that EGL is the preferred method going forward, but GLX is
the tried and tested method that we know works. So if we detect issues with
EGL, we want to avoid using it in favor of GLX.
Also add a GDK_DEBUG=gl-egl option to force EGL at all costs and not try
GLX.
Currently GTK can be built with G_ENABLE_DEBUG which enables various debug code and parsing
of those env vars, or without, which instead of parsing them prints a warning if they are set.
While building with G_ENABLE_DEBUG isn't strictly needed it's the only way to make GTK_DEBUG=interactive work,
which is a nice thing to have always.
This enables parsing of those env vars in any case and allows specific values being marked as also
available when not built with G_ENABLE_DEBUG (interactive for example). If not built with G_ENABLE_DEBUG
then all unavailable values will be marked as such in the help output and a note is added that
GTK needs to be built with G_ENABLE_DEBUG to use them, which should help discoverability.
Include docstrings and format the list of supported
values better.
Also, add the same warning we have for GTK_DEBUG when
the environment variable is ignored.
This adds a GDK_DEBUG=default-settings flag which disables reads
from xsettings and Xft resources, and enables this for the testsuite.
This is one less way to get different testresults depending on the
environment. In particular, it was failing the css tests for me
due to getting the wrong font size because i have a different dpi.
This uses the new sysprof-3 ABI to implement the capture writer. It also
uses the statically linked libsysprof-capture-3.a that is provided with
Sysprof for the capture writing to ensure that we do not leak any symbols
nor depend on any additional libraries.
The GTK_TRACE_FD can be used to pass a FD for tracing into Gtk. Sysprof
uses this when the Gtk instrument is selected for recording.
If SYSPROF_TRACE_FD is set in the environment,
interpret it as an fd to write profiling data
to.
If GTK_TRACE is set, write profiling data
to a file with name gtk.$PID.syscap.
This is named gdkconstructor.h to avoid any possible conflicts. This fixes
the current usages of G_HAS_CONSTRUCTORS, as that header is not installed
by glib.
Similar to what has been done recently for DESKTOP_AUTOSTART_ID [1],
we need to get rid of this call to g_unsetenv() in the displays'
backends for X11 and Wayland, so that it's guarantee to happen any
thread is created, while still being accessible when needed.
Let's stash the value of this environment variable when loading the
GDK library, and provide a private method so that it can be retrieved
from the displays' backend when implementing gdk_display_make_default().
[1] https://gitlab.gnome.org/GNOME/gtk/commit/22269902
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/979
