We were leaking buffers. This wasn't caught by valgrind and friends
because it was shared memory (with the compositor), but top(1) would
instantly see memory consumption of the app and the shell go through the
roof.
We were calling _gdk_surface_update_size() every frame, even if the
window size didn't change. This would cause us to discard all cached
buffers and redraw the whole screen.
This was BAD.
guint32 is used as part of the protocol in broadway backend.
Memory size declared with it was mistakenly replaced with size_t type
which does not guarantee being 32bit on all platforms, leading to a crash.
These events don't make sense on physical devices (for starters, they
are relative to the logical pointer position). Use this device for
those events, also happens to be what the upper parts expect of them.
Commit 97b5fad131 was a forward port from a gtk3 patch, but the hunk
was applied on the wrong bits of code.
Ensure the initialization paths also do mark settings read from the
portal as valid, so the checks for optional/newer settings actually have
the expected result. It is also desirable to mark settings as valid
after configuration changes (as that patch did effectively do), but not
enough to fix all situations.
If our opaque region is the entire surface, then we can make the OpenGL
context opaque like we do for decorated windows. This improves performance
as the compositor does not need to blend the surface with the contents
behind the window.
Use the infrastructure already available to look up keys, instead.
This does the right thing and looks up the setting across all
sources.
Fixes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3680
The debug spew for printing out supported buffer
formats was missing a bunch, among them the fp16
formats that are interesting for HDR support.
Add them.
Note that we still only support ARGB8888. But
at least we can print out what don't support.
We do not need to translate this on the CPU when we can instead push it
to the GPU in the same format and allow it to swizzle.
This fixes a huge number of memory allocations found while uploading the
GTK animation in widget-factory.
Just compiling these out means you have to write code slightly differently
so that you don't end up with "if ();" afterwards.
This adds a "do {} while (0)" so that we're still semantically a statement
but will also compile out.
My reading of the code is that gdk_drop_new() is not
consuming the content formats it is given, so the caller
must not pass a new reference.
Needs testing on Windows.
Whenever we communicate targets, we need to the union, otherwise
we don't tell the other side about our serialization. This makes
drops of images from gtk4-icon-browser to gimp and libreoffice
succeed in transferring data.
Fixes: #3654
When creating the output stream for a drop, we must
pass the mimetypes we support, otherwise the picking
of the right handler does not work.
Fixes: #3652
This attempts to fix the counter-intuitive resizing of surfaces in GTK4 where
the surface grows or shrinks at the right and/or bottom edge when the window
resized from the top and/or left edge(s).
This is not yet perfect as the window stutters upon resizing from the top
and/or left edges, but at least makes resizing more intuitive.
Remove the 'resized' member from the GdkWin32Surface structure, as we already
have a structure with a member that keeps track of whether a surface is being
resized, so we can just use that and avoid some confusion in the process
Sometimes the size will exceed the minimum bounds. For example crazy
applications like the widget factory that contains the world, or when a
user interactively resizes a window to be larger than the monitor the
window is on is.
The former is questionable, but the latter is not, and from here we
can't really see the difference, so just stop complaining.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/3035
This adds a "release" destructor for the gtk_surface1 interface which
signals to the server that a surface has been destroyed on the client
side, which the current "destroy" does not do.
Ideally the protocol would have specified a destroy request marked as
destructor to handle this automatically, however this is no longer
possible due to the destroy method being implicitly generated in the
absence of an explicit request in the protocol. Adding a destroy request
marked as destructor now would generate a new destroy method that
unconditionally would send the request to the server, which would break
clients running on servers not supporting that request.
