Created attachment 310875 [details] [review]
tests: Don't rely on latency for actually showing Wayland windows

Review of attachment 310875 [details] [review]:

Thanks for the trying this out and tracking down the problem! Change:

 "On Wayland this is not enough; the client also needs to actually paint something for a window to be mappable."

To:

 "Now that we wait to show a Wayland window until the first buffer is attached (see bug 750552), we need to make sure that we attach a buffer before assuming that we have the final stacking order"

Otherwise it looks like I landed the tests without making sure that they work ;-) I'd also change the subject message to something to something like "tests: make sure that we attach buffers for Wayland windows"

In terms of the implementation, my first reaction to this was "no way - everything but 'wait' is async - the handling for this needs to be in 'wait'"

But we do have the idea that when you show a window, GTK+ is supposed to deterministically proceed on and paint the first frame (X11) / attach a buffer (Wayland) without waiting for any events back from the window system, so this could conceivably fit the idea that the commands are "async" - we're still not waiting for Mutter to do anything - we're just letting GTK+ get to the point where it will attach the buffer. So I'm OK with the patch, and an alternative would be considerably more complex.

::: src/tests/test-client.c
@@ +45,2 @@
 static void
+on_window_painted  (GdkFrameClock *clock, GdkWindow     *window)

a) parameter alignment.
b) the name looks like you've changed strategies? use on_after_paint as the name.

@@ +153,3 @@
+
+      /* When a Wayland client, we cannot be really sure that the window has
+       * been mappable until after we have painted. So, in order to have the

Is "mappable" a concept in Wayland? If not, I'd be more specific and say "Mutter will not show a Wayland window until we've painted and attached the first frame"

@@ +161,3 @@
+      g_signal_connect (frame_clock, "after-paint",
+                        G_CALLBACK (on_window_painted), gdk_window);
+      g_main_loop_run (loop);

I'd rather you just allocated a local loop here and passed that as the user data.

Created attachment 311994 [details] [review]
tests: Don't rely on latency for actually showing Wayland windows

The test runner sends a "show" command to the test clients and assumes
this was enough work done by the client to enable the compositor to map
the window. Now that we wait to show a Wayland window until the first
buffer is attached (see bug 750552), we need to make sure that we attach
a buffer before assuming that we have the final stacking order.

So, to in order to continue relying on "show" to be enough to actually
show a window, let the test client wait until it has drawn the first
frame.

This makes the tests using Wayland clients test non-flaky.

Attachment 311994 [details] pushed as 5054b2a - tests: Don't rely on latency for actually showing Wayland windows