Expose NonBlocking Polling Function of WindowEvents #417
Description
Summary of feature
Add new Feature that allows the consumer to only poll for SOME window-events.
Comments
i did that in sdl2 so i explain it via SDL2:
in sdl there is the feature PollEvent,
it only returns 1 event and tells the consumer if there are more events in the queue
the mainstream usage is something like that:
while (1) {
SDL_Event event;
while (SDL_PollEvent(&event)) {
/* handle your event here */
}
/* do some other stuff here -- draw your app, etc. */
}now there is some problem with this approach,
at least on windows, read something about that on mac it doesnt appear, but cant find anymore
for some reason while dragging a window or simply click on the title bar, or resise, or click on the X button to close
there additional messages generated while doing above actions (its a theory of me, no proof)
this will keep the above loop alive as long as above states are active (dragging resising,...)
by only polling some events per "Tick" into another message queue i was able to not let the mainthread block
ofc it needs abit time to fill the additional list, but thats not much and should be kept afap (because of locking)
and ofc the consumer has to set some sort of messageBufferSize and another thread processing and cleaning this message queue
as i switched to silk, my "workaround" doesnt work anymore, because there is no feature to get only SOME messages,
i have to use DoEvents which i suppose is doing something like the "hardcoded" loop above.
if there would be a feature to only get some messages, that would be nice
im only hobby coder so i hope this all isnt complete bullshit :)
HINTS:
in sdl:
its straight forward there is PollEvent
in glfw:
it maybe could be done with the help of glfwWaitEventsTimeout()
from glfw.org:
Event processing
GLFW needs to poll the window system for events both to provide input to the application and to prove to the window system that the application hasn't locked up. Event processing is normally done each frame after buffer swapping. Even when you have no windows, event polling needs to be done in order to receive monitor and joystick connection events.
There are three functions for processing pending events. glfwPollEvents, processes only those events that have already been received and then returns immediately.
glfwPollEvents();This is the best choice when rendering continuously, like most games do.
If you only need to update the contents of the window when you receive new input, glfwWaitEvents is a better choice.
glfwWaitEvents();It puts the thread to sleep until at least one event has been received and then processes all received events. This saves a great deal of CPU cycles and is useful for, for example, editing tools.
If you want to wait for events but have UI elements or other tasks that need periodic updates, glfwWaitEventsTimeout lets you specify a timeout.
glfwWaitEventsTimeout(0.7);It puts the thread to sleep until at least one event has been received, or until the specified number of seconds have elapsed. It then processes any received events.
If the main thread is sleeping in glfwWaitEvents, you can wake it from another thread by posting an empty event to the event queue with glfwPostEmptyEvent.
glfwPostEmptyEvent();Do not assume that callbacks will only be called in response to the above functions. While it is necessary to process events in one or more of the ways above, window systems that require GLFW to register callbacks of its own can pass events to GLFW in response to many window system function calls. GLFW will pass those events on to the application callbacks before returning.
For example, on Windows the system function that glfwSetWindowSize is implemented with will send window size events directly to the event callback that every window has and that GLFW implements for its windows. If you have set a window size callback GLFW will call it in turn with the new size before everything returns back out of the glfwSetWindowSize call.