Collect input counts over one frame to avoid missing inputs within the same frame

[RoryO]

In response to #2787 I'm attempting a low impact way of addressing dropped inputs over the course of a frame. This can happen at the standard 60hz refresh with high frequency devices like high quality keyboards. It's also possible this happens when frame rate drops.

This changes the KeysDown array from an array of bits to an array of unsigned integers. That change alone has no affect on any code since a standard C++ bool is 1/0 and not a special object. This means existing implementations can gradually adopt this change along with widgets. From there in the example win32 impl when we process pending window message we total up all the down events for that key. This also introduces KeysUp and KeysUpPrev arrays of unsigned integers. When processing the window messages, tally the up events into the KeysU array.

We have two Up arrays so we can process Up events in the next frame. Upon NewFrame, we subtract the Down events from Up events that occurred the previous frame. This way we capture the down event and can process it when there is a down and up within the same frame.

I thought about also changing MouseUp/Down in this way. The more I thought about it the more I think that may actually make the problem worse with errant clicks in areas the user doesn't expect. Currently it appears the input interface checks if the mouse is down and then gets the current position of the mouse. This could lead to situations where the last recognized mouse position on a lagged frame was different than the position the user actually clicked causing inputs they didn't expect. I can't think of a quick slot in solution for that situation like this keyboard input one. I think we'd need either encoding a mouse click with the coordinates of the mouse at that moment in time or go full on event list and replay the events in order every frame. Both of those are a monumental undertaking and may not be worth the effort.

[ocornut]

FYI dear imgui 1.87 WIP now uses a new IO api (e.g. io.AddKeyEvent() io.AddMouseButtonEvent() etc.) which implement an input trickling queue, normally solving this problem correctly and everywhere for all types of inputs. We'll monitor feedback and expect bugs to have creeped as we reoverhauled that system.

See e.g.

• new IO api b8e56dc
• input queue 7374b96

Also see #4858 for a general overview.