Make ControlFlow::Wait the default

[daxpedda]

After some discussion in #3105 I was asking myself why Poll is the default. So I wanted to know what everybody thinks about switching the default to Wait.

I will make a follow-up to try and improve the documentation around our recommendations on which ControlFlow to choose, but wanted to keep it separate.

[kchibisov]

I think the issue we should consider is that initial iteration, should still be with Poll, however anything further is with the default behavior. The reason behind is that you technically have events, and the event is the StartCause, but with Wait you'll wait for the actual events coming from the user or the windowing system, which might not be desirable for the first iteration.

What we should do, is to just switch the user default, but we shouldn't change the way kick start of the loop works, since we always have an event (StartCause::Init) and we simply need a wakeup, which Wait internally in the backends might not deliver it.

I'd also suggest to emphasize on the Poll internally, for the first loop iteration, like it's done in Wayland/X11, so you have more predictable startup, which should be fine across the backends.

[kchibisov]

You can keep the Poll here, I think motivation is to do the first loop iteration non-blocking, because if you see the code, it won't get reset anymore? We just need to change the user default, but if the code really hardcodes the poll it's likely only a one time action.

[daxpedda]

I think the issue we should consider is that initial iteration, should still be with Poll, however anything further is with the default behavior. The reason behind is that you technically have events, and the event is the StartCause, but with Wait you'll wait for the actual events coming from the user or the windowing system, which might not be desirable for the first iteration.

I'm not following. If StartCause is there, shouldn't that kickstart the initial event loop? Or are you saying that some backends just don't work correctly if you start with ControlFlow::Wait?

[kchibisov]

@daxpedda yes, that's what I'm saying that they could go to sleep in such cases for the first iteration, because the event by its nature, is synthetic, so it can act like it won't wake up the event loop. I think Wayland/X11 backends will need more tuning than what you've done, but there's no issue to keeping the Poll for the first iteration internally, since it makes the most sense.

In practice, this won't change anything for the end users, since the default polling is still Wait, so after the first iteration.

[daxpedda]

In practice, this won't change anything for the end users, since the default polling is still Wait, so after the first iteration.

I assume I still have to put it back to ControlFlow::default() after the first iteration?
Another question would be if the user uses EventLoopWindowTarget::control_flow() would they not see that the ControlFlow is Poll?

[kchibisov]

I assume I still have to put it back to ControlFlow::default() after the first iteration?
Another question would be if the user uses EventLoopWindowTarget::control_flow() would they not see that the ControlFlow is Poll?

Maybe it's not clear what I suggested, but I'll clarify:

1. When first iteration happens, the internal behavior is if the Poll was used or it could be something else, if the backend can guarantee that it'll properly wakeup for the first iteration. The change I've suggested is a conservative approach to that, since I know that it won't break anything internally in the backends.
2. After the first iteration, the behavior set by the user is what should be used, so in
   our case, the EventLoopWindowTarget::control_flow(). The default is Wait, but we shouldn't use the ControlFlow::default() in the backends code, we should use the value used by the users, and when the backends requires special polling for a short period of time to remain correctness it should switch to it. But we must not use the ::default() instead of the Poll.
3. Users always see the default as a Wait or what they set, if the backend changes the way it polls internally for correctness reasons, is up to the backend, it was like that even before.

What you confuse is the policy with the behavior, users are setting the polling policy, how the backend follows that policy is up to the backend. It could use different polling internally, but it should look like the Wait behavior for the end user.

[kchibisov]

So, how the change should look is that you simply change the default on the ControlFlow, and then ensure that the backends don't rely on that default being Poll, like ios. Instead they should simply specify the Poll when they need it.

[daxpedda]

After some IRC conversations we figured out that this was already an issue before this PR.
See #3107.