It is possible that the window gets unrealized while a handle to its
surface is exported. This, naturally, invalidates the handle, so there
is nothing left to unexport. We should just note that and do nothing,
rather than crashing.
Fixes a crash when a portal-backed file dialog parented to a window is
closed after the window it was parented to.
Reported-by: Ivan Molodetskikh <yalterz@gmail.com>
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
When setting a new paintable, we don't need to queue_resize() when it's
the same size as the old paintable.
This is especially useful when pictures are used in a listview or
gridview and different rows display images of the same size.
It is useful to track down mysterious crashes in ci, but it causes
sporadic test failures, so disable it for now, until we have another
mysterious crash.
Upon joining the a11y tree. And do so recursively, as long as the parent
is also not a widget.
As for the explanation, please grab a mug of your favorite drink. It's
a little complicated.
GTK realizes AT contexts in 3 situations:
1. When it's a toplevel, it's realized unconditionally
2. When the widget is focused
3. When the accessible is appended to a realized parent
Most importantly, GTK lazily realizes accessibles, and does not realize
child accessibles recursively.
Clearly, conditions 1 and 2 only ever happen for GtkWidgets, which are
accessible objects themselves. These two conditions will handle the vast
majority of cases of apps and platform libraries.
However, there are non-widget accessibles out there. GTK itself offers a
non-widget accessible implementation - GtkAtspiSocket - which is used by
WebKitGTK.
Now, let's look at WebKitGTK use case. It'll demonstrate the problem
nicely.
WebKitGTK creates the GtkAtspiSocket object *after* loading most of the
page. At this point, there are 2 possibilities:
1. The web view widget is focused. In this case, the AT context of the
web view is realized, and GTK will realize the GtkAtspiSocket when
it is added to the a11y tree (condition 3 above).
2. The web view widget is *not* focused. At some point the user focuses
the web view, and GTK will realize the AT context of the web view.
But remember, GTK does not realize child accessibles! That means
GtkAtspiSocket won't be realized.
This example demonstrates a general problem with non-widget accessibles:
non-widget accessibles cannot trigger conditions 1 and 2, so they're
never realized. The only way they're realized in if they happen to be
added to an already realized accessible (condition 3).
To fix that, the following is proposed: always realize non-widget
accessibles, and also of their non-widget accessible parents. This is
not ideal, of course, as it might generate some D-Bus chattery, but GTK
does not have enough information to realize these objects at more
appropriate times.
Move the code that realizes an AT context if the parent is realized,
into to a separate function. This will make the next patch easier to
read.
No functional changes.
... and print if a format is advertised.
We now use the same style of message and use the term "advertise" for
formats that will be available via GdkDisplay::dmabuf-formats and
"supports" for formats the backend pretends it can handle but don't
want to advertise them.
Instead of only printing the advertised dmabuf formats, print all
supported ones. This is now useful information because we will try to
use them when downloading.
Fixes me looking like I don't know what I'm talking about on IRC when
claiming that llvmpipe can't do dmabufs, because it only supports linear
ones and we didn't print those.
We want to make the distinction between GdkSurface's and native Windows
HWNDs clear, and we don't want to confuse between GdkSurface's and
Vulkan surfaces.
In order to help us in our refactoring, make the distinction between Gdk
surfaces and native Win32 HWND clearer in terms of the variables that we
used, and in the comments in the code.
Also, group forward function prototype declarations in one place, and
drop some unneeded items in gdkprivate-win32.h to fold them into
gdksurface-win32.c, as they are only used there.
We don't need our own mechanism for device selection; mesa has a
Vulkan layer that works perfectly fine for this purpose; just set
MESA_VK_DEVICE_SELECT.
If that flag is set, we keep the bounds of the original node when
rendering the modified node.
Gets around the replay test having to draw a transparent color node to
ensure the same bounds.
This reverts commit fd02afa2e4.
We don't want to remove the GL renderer from our tools yet, because we
use those tools for manual testing and having it available is useful.
In particular, reinstate the GL renderer for rendernode-tool benchmark.
