We are using so many internal extra features that it is no longer a good
idea to use these functions.
And they aren't really used anyway.
These extra features are also constantly in flux and rely on internal
APIs, so exposing them would just cause extra pain.
By using the inlining macro trick, we can work around deprecation
warnings from removing this function as a public API, which will happen
in the next commits.
GLContexts marked as surface_attached are always attached to the surface
in make_current().
Other contexts continue to only get attached to their surface between
begin_frame() and end_frame().
All our renderer use surface-attached contexts now.
Public API only gives out non-surface-attached contexts.
The benefit here is that we can now choose whenever we want to
call make_current() because it will not cause a re-make_current() if we
call it outside vs inside the begin/end_frame() region.
Or in other words: I want to call make_current() before begin_frame()
without a performance penalty, and now I can.
... and pass the opaque region of the node.
We don't do anything with it yet, this is just the plumbing.
The original function still exists, it passes NULL which is the value
for no opaque region at all.
If an image description query is running while the surface gets
destroyed, we were not properly cleaning up, causing the callbacks to be
emitted on freed variables.
We were comparing with destination stride, not with source stride, and
in rare cases when those were different, this would trigger aborts in
the testsuite.
Each time we create a new window, we create a new EGLSurface. Each time
we destroy a window, we failed to destroy the EGLSurface, due to passing
a GdkDisplay instead of a EGLDisplay to eglDestroySurface().
This effectively leaked not only the EGL surface metadata, but also the
associated DMA buffers. For applications where one opens and closes many
windows over the lifetime of the application, and where the application
runs for a long time; for example a terminal emulator server, this
causes a significant memory leak, as the memory will only ever be freed
once once the application process itself exits, if ever.
Fix this passing an actual EGLDisplay instead of an GdkDisplay, to
eglDestroySurface().
This matches what the gpu renderer does when printing
colorstates.
It also avoids it printing "S*RGBA8" for the format and instead prints
"SRGBA8(p)" now.
Converting to and from xyz turns out to be more difficult than
expected, depending on what whitepoint you choose, And different
specs choose different whitepoints, so we can't directly map
css xyz to cicp xyz anyway.
Add a function for converting a single color from one
color state to another. This is a generalization of the
already existing function to convert a GdkRGBA to another
color state.
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.
When finalizing a subsurface, we need to make sure it is removed
from the sibling lists in its parent, or bad things will happen.
This should crashes seen in Epiphany nightly.
Fixes: #6891
convert_func2 is a 'from' conversion function, ie it expects to
be passed the target color state. This was wrong both in
gdk_memory_convert and gdk_memory_convert_color_state.
This is widely assumed, but is not guaranteed by Standard C, and is
known to be false on CHERI architectures (which have 64-bit sizes and
128-bit tagged pointers). Add a static assertion to ensure that GTK
will not build on platforms where this assumption does not hold.
As discussed on GNOME/gtk!7510, if GTK switches from gsize to uintptr_t
as its representation of the underlying bits in a pointer, GTK maintainers
would prefer that to be done project-wide so that it's done consistently,
after which this static assertion could be removed.
At the time of writing, GLib makes the same assumption (GNOME/glib#2842),
but GLib contributors are gradually removing it (mostly by replacing gsize
with uintptr_t where a pointer-sized quantity is needed). Finishing
that work in GLib would be a prerequisite for being able to make GTK
work on the affected platforms.
Signed-off-by: Simon McVittie <smcv@debian.org>
Some callers of these functions ask to copy 0 items from a NULL source,
which would be valid if they were copied in a loop (because NULL would
never be dereferenced), but is declared to be undefined behaviour for
Standard C memcpy. Guard the call to memcpy so that we only call it
if we have more than 0 items, and therefore should have a non-NULL
source pointer.
Detected by running a subset of the test suite with
-Dsanitize=address,undefined on x86_64.
Signed-off-by: Simon McVittie <smcv@debian.org>
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>
