Order of events on window creation

[raphlinus]

There's a panic in linebender/xilem#1 on window creation with the Wayland back-end. This probably has to do with the order of events on window creation being different. It certainly would be possible to fix this by making the xilem code more robust, but I think it's better to fix this at the glazier level, making the order of events more consistent from platform to platform, to reduce the burden on other potential clients.

Also see https://xi.zulipchat.com/#narrow/stream/351333-glazier/topic/Running.20callbacks.20when.20building.20windows.2E where this was discussed a bit.

[raphlinus]

Taking a closer look, I'm now more inclined to fix this by making xilem more robust (I think app render + view tree rebuild should be more loosely coupled with paint, in particular can be skipped when there are no events that have been processed or async futures that have completed).

So perhaps we close this issue.

[richard-uk1]

I'm personally in favor of making glazier as easy to use as possible - including documenting the guarantees we make w.r.t. timings and orders of events.

[richard-uk1]

I've thought about this some more, and I think it is a complex topic. The window creation logic goes something like

1. User requests a new window with a size hint.
2. Library tries to create a window and if successful, returns a handle. The size may be different to the one requested.
3. User uses window handle to create graphics context etc.
4. User runs the application loop which blocks until the app is closed.

The things I'm not sure of are:

• How does the library do stuff if the application loop isn't running? Perhaps this isn't an issue since we just make these operations blocking.
• How does window creation happen once the event loop is running? Maybe there is a 'new window' event that is added to the queue and handled once everything before it has been dispatched.

I find all this stuff a bit mind-blowing.