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.
Remove all the roadblocks we've put up to keep implicit modifiers
out. Our importing code already handles them as a signal that says
'No modifiers, please!'. Now we just hope for the best and pass
things along.
This is necessary since some drivers won't produce any explicit
modifiers.
We were confusingly printing "supported format" for dmabuf formats
that we end up not adding to our list of supported formats. Don't
do that, it is confusing. At the same time, we shuold print out
the linear formats we support via mmap.
Add an implementation of GdkDmabufDownloader that uses
gsk_renderer_render_texture + GL texture download.
Since gsk isn't threadsafe, we do the download in the main thread,
taking care to not disturb the current GL context of whatever is
going on there at the time.
And since gsk renderers are expensive to create, we cache it
in the display.
Note that gsk does not yet have any special support for
dmabuf textures, so for now, they will always get downloaded
and then reuploaded as GL textures.
Trying to use it is a programming error, applications should have code
that uses real modifiers.
Also add a check to the formatsbuilder so our code doesn't include the
invalid modifier by accident.
We don't really know how to deal with it, so better force applications
to figure out what to do.
When adding the formats of a downloader, allow them to return FALSE to
mean "This method is not supported", which is a useful way to opt out
when checking GL or Vulkan extensions and finding out that the desired
one isn't supported.
This seems to be what everyone does, so we should do it, too.
Previously it was assumed that an fd of -1 would mean reusing the
previous fd with a different offset, but that seems to be uncommon.
We did have 4 ordering variations of ARGB straight,
but only 3 premultiplied. Add the missing one.
Update all the places where we switch over memory formats.
1. Split out the download function from the mmap'ing of the plane(s)
2. Make the code mmap() all the planes
3. Determine size using lseek() as documented by libdrm, instead of
trying to guess it from the format.
4. Fix some bugs, like switcheroos of width and height
Tries to sanitize the dmabuf to conform to the values expected
by Vulkan/EGL which should also be the values expected by
Wayland compositors
We put these sanitized values into the GdkDmabufTexture, by
sanitizing the input from GdkDmabufTextureBuilder, which are
controlled by the callers.
Things we do here:
1. Disallow any dmabuf format that we do not know.
1. Treat the INVALID modifier the same as LINEAR.
2. Ignore all other modifiers.
3. Try and fix various inconsistencies between V4L and Mesa,
like NV12.
*** WARNING ***
This function is not absolutely perfect, you do not have a
perfect dmabuf afterwards.
In particular, it doesn't check sizes.
Vertex arrays are available in GL and in GLES >= 3.
We don't check for the GLES extension that provided
vertex arrays in older GLES, since that requires
using different API.
This api avoids version checks all over the place.
Make gdk_memory_format_gl_format take the GdkGLContext,
instead of just a gles boolean. This will let us
check for extensions that may be needed for certain
formats.
Update all callers.
We always have a display - the default display - so there's no need to
accept NULL.
Plus, we need a display when building the texture, so accepthing NULL
wouldn't even make sense.
Includes update to defaultvalue test.
We are returning interned strings here, and
g-i seems to have trouble interpreting the const,
so lets help it out by being more explicit with
our annotations.
Fixes: #6167
GdkDmabuf is a struct encapsulating all the values of a dmabuf, so
nothing to see here.
GdkDmabufDownloader is a vtable for a thing that can download dmabufs.
For now only one implementation exists, so this just looks like a ton
of work for no benefit.
The only neat thing is that gdkdmabuftexture.c got a whole lot tidier.
Add a new debug flag for dmabuf-related information,
and use it in gdkdmabuftexture.c.
This will let us separate out dmabuf debug spew from
opengl debug spew.
These are the dmabuf formats that we can import
into a GL context as an EGLImage, and successfully
download.
We skip the GdkDisplay:dmabuf-formats property
in the default value tests, since the nominal
default value is NULL, but the actual value is
constructed on demand.
Add an implementation of GdkDmabufTexture.
For now, this implementation is rather minimal,
since we need a roundtrip through GL to convert
most nottrivial formats.
Add a builder for a new GdkTexture subclass that
wraps dmabuf buffers on Linux. For now, this is
just an API. The implementation will follow in
subsequent commits.
The C standard does not specify whether the underlying type of an enum
is signed or unsigned, and until C23 there was no way to control this
explicitly. GCC appears to make enums unsigned unless there is a
negative value among cases of the enum, in which case it becomes signed.
MSCV appears to make enums signed by default.
A bitfield of an enum type (which is not specificied in the C standard
either) behaves as if it was an instance of a numeric type with a
reduced value range. Specifically, a 'signed int val : 2;' bitfield will
have the possible values of -2, -1, 0, and 1, with the usual wraparound
behavior for the values that don't fit (although this too is
implementation-defined).
This causes the following issue, if we have:
typedef enum
{
GTK_ZERO,
GTK_ONE,
GTK_TWO
} GtkFoo;
struct _GtkBar
{
GtkFoo foo : 2;
};
and then assign bar.foo = GTK_TWO and read it back, it will have the
expected value of 2 (aka GTK_TWO) on GCC, but a value of -2 (not
matching any of the enum variants) on MSVC.
There does not seem to be any way to influence signedness of an enum
prior to C23, nor is there a 'unsigned GtkFoo foo : 2;' syntax. The only
remaining options seems to be never using enums in bitfields, which is
what this change implements.
In practice, this fixes GdkPipeIOStream crashing with an assertion when
trying to copy-paste in-app in MSVC builds on GTK.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Using "1 << x" means that we are shifting a signed 32bit integer, but we
want a gsize, which is an unsigned 64bit integer.
So now we don't overflow anymore if the array reaches a size of 2GB.
Gdk-Win32 uses GetClientRect() internally to query the surfaces coordinates,
but this API may fail in some transient contexts (observed when iconifying
a maximized window).
Check if the rect area is null, and don't update the surface position in
that case. This will keep the current surface size, until Win32 notifies
the new valid window state later.
This prevents using a nulled next_layout for toplevel size computation,
which would break widgets allocation once notified on gtk side.
Fixes#5724Closes#5724
At the moment of launching/activating an application, the
keyboard focus may be on a transient surface that quickly
disappears after activation. If this happens, and the
compositor handles surface destruction before the activated
application gets to reply, the activation request may be
deemed outdated, and the "demands attention" paths be taken.
Peek the toplevel from the focus surface, as that has larger
guarantees to remain valid for the whole duration of the
operation.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5820
