The outlook for mutter supporting this in GNOME 47 are cloudy,
so lets flip the switch back. You can still set
USE_POINTER_VIEWPORT in the environment to try this code.
When the compositor sends us an image description, we currently happily
reuse it.
However, those image descriptions may contain optional properties that
we do not handle - example: reference white level. So if we were to
reuse that image description, we would set a wrong reference white
level.
To avoid issues like that, never use compositor-provided image
descriptions.
However, query those image descriptions and map them to the closest
GdkColorState, so that we can quickly look up *our* version of that
image description and use that one.
Unfortunately the format string for a size_t, `%zu`, is not portable
to all Windows compilers, and the appropriate format string for the
fundamental type that implements size_t varies between platforms
(typically `%u` on 32-bit platforms, `%lu` on 64-bit Linux or
`%llu` on 64-bit Windows).
In gtk-demo, cast the number of search results to long, to avoid
breaking up a translatable string.
Elsewhere, use GLib's abstraction for this.
Signed-off-by: Simon McVittie <smcv@debian.org>
Main changes:
1. Avoid invalid writes by not passing pointers to a GArray that
realloc()s its data
2. Use a hash table to store image defs, instead of an array. This
requires a custom hash/equal function
3. Make image desc computation sync, so that setting a cs always
succeeds or always fails and doesn't depend on timing.
4. Add a few debug messages in failure paths. For lack of a category,
they ended up in MISC.
This happens when buffer creation fails in `get_dmabuf_wl_buffer()` and
we manually call `listener->release (data, NULL)`.
Fixes: 2478dd8322 ("subsurface: Split a function")
This is a still experimental protocol (thus the xx prefix).
We are using it go obtain information about the compositors
preferred color state, and pass that on to our rendering machinery.
The currently supported color states are srgb, srgb-linear, rec2100-pq
and rec2100-linear. We don't have any support for ICC profiles.
Unlike other protocols, keep the support code for this protocol
fairly isolated behind wrapper objects, since the protocol is
still subject to change.
begin_frame is the place where we make decisions about the format,
depth and colorstate for our rendering. Make these calls take the
surface color state into account.
In particular, if the surface colorstate is suitable for GL_SRGB,
and we don't need high depth, set things up for that.
The settings portal is reporting enums as string values, so
we need to translate this setting back to what we need.
Fixes
(gtk4-demo:18902): GLib-CRITICAL **: 19:06:14.783: g_variant_get_int32: assertion 'g_variant_is_of_type (value, G_VARIANT_TYPE_INT32)' failed
that could be seen in recent nightly flatpaks.
Make begin_frame() set a rendering colorstate and depth, and provide it
to the renderers via gdk_draw_context_get_depth() and
gdk_draw_context_get_color_state().
This allows the draw contexts to define their own values, so that ie the
Cairo and GL renderer can choose different settings for rendering (in
particular, GL can choose GL_SRGB and do the srgb conversion; while
Cairo relies on the renderer).
We have code with proper error handling for dmabuf export, we can just
try to use it.
And if it doesn't work, we don't offload the texture like before.
But it does work - at least for me.
Instead of hardcoding which textures we presumably support, just try
creating a buffer and use the failure of that for the error message.
This makes the error message a bit less obvious, but it makes it
possible to refactor the get_buffer() code without having to deal with
the error path.
If we want to improve the debug message, we can start putting debug
messages into the get_buffer() function.
But I think this is good enough.
We are seeing posix_fallocate fail with ENOENT occasionally.
This shouldn't happen according to the docs, but it does. Fall back
to ftruncate if it does. It gives us less guarantees, but it makes
the ci not fail so much.
The unary (closure) annotation is for function pointer types; function
arguments that represent the user data to be passed to the callback are
annotated on the callback argument itself, with (closure arg-name).
This protocol lifts some functionality from the gtk-shell protocol,
namely the ability to tag dialogs as modal. Ensure to use this
new protocol if available for the task, instead of the gtk-shell
protocol.
Make the info about the required protocols an array of definitions
again (a dict instead of an array this time) and add a field that
may be used for version checks of the wayland-protocols found.
Also, make it possible to have versioned protocols in-tree. Both
of these things will allow us to ship in-tree copies of wayland-protocols
without necessarily having to bump the version we depend on.
Use a format of
[XXX] SYMBOL DETAILS
where SYMBOL indicates the offloading status:
🗙 - no offload
▲ - offload above, with background
△ - offload above, no background
▼ - offload below, with background
▽ - offload below, no background
Do the same checks for background coordinates that we do for the
subsurface coordinates themselves: they must be integral in both
application and device pixels.
Spew a bit less per-frame. Unfortunately, we still spew for
every frame, and fixing that would require more extensive
refactoring to centralize all logging in gskoffload.c
Add a high-level setting that gives us more freedom to tweak
font rendering knobs according to our needs. It has a 'manual'
value that lets users continue to influence font rendering using
the low-level font-related settings as before.
Once the schemas have this, we can support setting this session-wide.
See https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/79
The initial implementation of 'automatic' font rendering is fairly
simplistic: if the monitor dpi is less than 200, prefer sharpness,
so turn on metrics hinting and slight hinting. If the monitor dpi
is at least 200, we both off.
