Fix window contents not resizing in lockstep with window resize on win32

[Osspial]

Before this change, when a WM_SIZE message was received it would throw a Resized event at the parent EventLoop thread and return immediately. There are two issues with that approach: win32 would proceed to resize the window before the application had been redrawn leading to visible black bars, and the immediate return would lead to win32 generating resize events at a rate far higher than any renderer could handle. The result of that is visible here.

This PR makes the win32 event loop thread sleep until the Resized event is processed by the EventsLoop struct, only returning after the event closure returns. This vastly decreases the number of resize messages sent, and delays resizing until after the application has handled the message. The end result is that resizing looks like this, for both poll_events and run_forever. There's a slight downside here in that the actual window resizing is slightly laggier and jutterier than it was previously, but this is an effect that is present even in official Microsoft applications and is far less noticeable than the window's contents failing to resize with the rest of the window.

[Osspial]

It looks like this may be a bigger issue on AMD cards (I have an RX 480), but it should still improve resizing slightly on NVIDIA cards.

[tomaka]

Is it necessary to have this "deferred wait" system? Can't we just skip waiting when the event was sent at initialization?

[Osspial]

We could skip waiting, but there would need to some way to tell the thread receiving events to skip waiting too. If that doesn't happen, receiving a resize event freezes the event loop until the next resize event comes in. Either way, one thread has to keep track of how many waits were skipped and doing it in the win32 event loop thread seemed easier.

[tomaka]

Couldn't we use a Condvar instead?

You'd have a Mutex<bool> and a Condvar, the bool representing whether the callback thread must block.
When WM_RESIZE is received, it puts true in the mutex and uses the condvar to wait until the events loop writes false in the bool.

[Osspial]

Yeah, I just re-implemented this patch with Condvar and it seems to work fine.

[tomaka]

You need to lock the mutex before calling send_event, otherwise it is possible that the event gets processed and notify_all() gets called before we even reach that point.

I think the best thing to do is to not call send_event here but directly context_stash.as_ref().unwrap().sender.send(event).

[tomaka]

I'd prefer is this function didn't exist.
if event_is_resize(event) can be replaced with if let Event::WindowEvent{ event: WindowEvent::Resized(..), .. } and it's just as clear in my opinion.

[Osspial]

I can move the check out of a function, but it can't happen as an if clause because Event doesn't implement Copy and is consumed by callback(event).

[tomaka]

Ah yes, sure.

[tomaka]

I think this function should also be removed. Even though it seems to violate DRY, I'd prefer is this was just copy-pasted in the two places where this is relevant. Having a function that must only be called under precise circumstances is never good IMO.

[tomaka]

Thanks!