wayland: Initially paint the window white so that they always exist

[elinorbgr]

This adds a dependency on the tempfile crate, but this was already a transitive dependency via wayland-window.

This PR uses the basic mechanism of wayland for passing memory buffers to paint the window content white once at creation, to ensure the window actually exists and can receive events, to avoid the issues like rust-windowing/glutin#884

This mechanism is guaranteed to always be available by the wayland spec, and does not pose any problem to initialize an EGL or Vulkan context afterwards.

closes #109

[mitchmindtree]

Awesome, I just tested the window example locally (on gnome) and can confirm that this does indeed draw a white window, allowing the window to receive events without issues.

The window did however look slightly strange. Only the top and left borders were shown - the bottom and right were not:

The example happens to work fine in weston however, so maybe this is another mutter-specific bug :(

Other than this, LGTM

[elinorbgr]

Actually, I don't think this is a mutter bug, but rather a resizing event poorly handled.

All other windowing mechanism than wayland have some way for a window to explicitly set its size (some kind of resize function), and winit uses it when necessary.

Wayland do not have that, rather the size of a window is implicitly defined by the size of whatever you put inside. As we also draw the decoration manually, this seems like a case where the size of the content and the size of the decorations got out-of-sync.

Whenever winit resizes itself after a demand of the display server, it generates a Resized event, that the user of winit is supposed to handle, either by resizing its drawing surface accordingly, or explicitly resize the window to a better fitting size. I believe what happened for you is that mutter directly suggested a new size to the window, winit followed it, but the contents were not updated (as nothing in the example is programmed to do it), hence the decorations appearing smaller than the actual content.

This should not be an issue with glutin, as it automatically resizes the EGL surface appropriately. So if my interpretation is correct, the glutin examples using winit including this patch should not exhibit the issue. Could you confirm it?

[mitchmindtree]

Ah yes you are correct, I just tested the glutin window example locally and can confirm that it does indeed behave correctly with this patch 👍

[tomaka]

Thanks