run_forever cannot bulk process events, unable to empty event queue

[ColonelThirtyTwo]

In a program that uses poll_events in an infinite loop, poll_events will process events until the event queue is empty. If multiple events are enqueued while the program is rendering, the program can process each of them before beginning the relatively expensive task of rendering the next frame.

With run_forever though, this sort of "bulk event processing" cannot happen. The callback does not know if more events are in the queue, so it must unconditionally render a frame to the user. But while rendering a frame, more events can be enqueued. If rendering takes too long, the input queue becomes filled with events, and the run_forever callback cannot process them fast enough as it has to process older events first.

This severely affects interactivity; the program appears to the user that the program is constantly "catching up" with what the user did seconds ago (this is particularly noticeable when moving the mouse, which causes many events).

---

There are a couple workarounds to this issue. The obvious one is to use poll_events instead. However, if the program only needs to re-render in response to user input (common in editors), rendering all of the time wastes CPU and power.

A more complicated workaround is to have the event loop forward all of its events to the program's own queue (such as std::sync::mpsc), which can implement a "check if empty function". This introduces complexity in the program, though, and it would be better if winit had a simpler interface.

---

The API described in #231 would solve this issue. The program can call get_event with a short timeout until no events are left, then render the frame and call get_event with an infinite timeout.

[tomaka]

Another work-around is to use the EventsLoopProxy.

[mitchmindtree]

Another work-around is to use the EventsLoopProxy.

This is what I normally do, however #266 currently makes this a bit tedious on X11.

[ColonelThirtyTwo]

I'm not sure how EventLoopProxy is supposed to help. I'm guessing you can spawn a thread that wakes up the main thread using EventLoopProxy if no events have been recieved in a short time, but that seems like a hack.

[Osspial]

Closing this, since the EL2.0 rework is in the process of getting onto master and it fixes the design issues brought up here.

[ColonelThirtyTwo]

@Osspial Wait, so you're saying the redesign that's not yet released rewrites this to fix the issue? If it's not released yet, then this isn't fixed and should not be closed. I'm glad it's at least getting worked on though.

[Osspial]

Sorry - I've been triaging stuff today, and may have gotten a bit over-zealous with closing stuff!

You're right that this shouldn't have been closed. The better solution would be to refer to this in the EL2.0 tracking issue. I'll go ahead and add that in there.

EDIT: actually, the eventloop-2.0 milestone exists for this reason.