Having trouble showing a window at all.

[meh]

Sorry for the noise on the issue tracker but I'm kind of lost as to where I could get help about this, in #rust nobody was able to help.

So, I'm working on a terminal emulator and I thought it would be cool to support Wayland too since it already works on X11 and macOS, but alas I'm having trouble showing a window at all.

I tried taking inspiration from winit/glutin since in the end I need an EGL context to pass to Cairo, when I realized it wasn't showing anything I blamed winit/glutin and scrapped everything, then I actually tried running the winit/glutin examples and none of them show a window either.

Then I tried the wayland-window and wayland-client examples, and they work perfectly, then I tried the glium examples and they work too, and now I have no clue about anything anymore because that doesn't make any sense.

The code can be found here, Window::new is called by the main thread, then the Proxy is extracted and given to a secondary thread with an event loop, and Proxy::surface is called by that event loop when required.

Do you see anything glaringly wrong that would result in no window being shown at all?

[elinorbgr]

I don't have a lot of time to check your code, but given what you describe, it seems like your issues comes from a subtle deadlock (which is for example the reason why glutin examples do not work): a wl_surface will not show on the screen before its contents are drawn once (in an EGL context, that means calling eglSwapBuffers() at least once).

If the wl_surface is not displayed, it won't generate any events. So if you enter your event loop, and that this loop blocks waiting for a wayland event before drawing the contents of your window at least once, your event loop will wait forever.

[elinorbgr]

If it is not the cause of your issue, I'll take a look at your projet, but I don't have enough time right now.

[meh]

I was suspecting a deadlock somewhere, but I wasn't entirely sure where it could be coming from, I'll try shuffling things around.

And no worries, I'm not in a rush, what you said already lets me try something that isn't just staring at the code 🐼

Thanks!

[meh]

Actually, is it safe to draw to a WlSurface from different threads?

As things are designed in my thingy the main thread deals with the platform dependant event handling, because that's how it works on macOS and Windows, the platform dependant loop then sends messages to a channel which is handled by a separate thread which is my event loop.

This separate thread with the event loop also does the rendering, would a deadlock happen in that case?

[meh]

Almost success with rendering, but I got the window to show!

Thanks for the help, it was something wrong on the EGL front, it wasn't actually doing anything! 🐼

[elinorbgr]

Actually, is it safe to draw to a WlSurface from different threads?

The wayland part of the lib is completely threadsafe, now it really depends on the method you use to draw on the surface.

If you are handling wl_buffer yourself, you should have a look at the release event associated to it. In your case, it seems you are using EGL+cairo? I guess only cairo's documentation will tell you whether it's threadsafe or not...

But if you just plan to use one thread for drawing and an other thread for your event loop, it should not be a problem at all.

[elinorbgr]

This separate thread with the event loop also does the rendering, would a deadlock happen in that case?

As long as you make sure the window actually exist on screen before blocking in your event loop, or that drawing is not blocked on the event loop, this issue should not bite you again. 😉