The AndroidInputReceiverSetup.slow_raw_input_doesnt_cause_frameskipping test definitely needs renaming, because it no longer tests anything of the sort.
I'm weakly against the change to dispatch multiple events in a single process_and_maybe_send_event(). Your comment is incorrect - there were no races: if consume() didn't read all the events from the fd then it would remain readable and we'd return to the dispatcher and immediately get called again.
When client-driven dispatch is available clients are going to expect to get a single event out of a single dispatch call.
**** So: ****
*) Rename or remove AndroidInputReceiverSetup.slow_raw_input_doesnt_cause_frameskipping
*) Don't loop in process_and_maybe_send_event()
Optional:
*) Maybe rename process_and_maybe_send_event()? I'm pretty sure it is now always going to send an event.
*) Test that you get at most one event sent per dispatch() on the AndroidInputReceiver?
The AndroidInputRec eiverSetup. slow_raw_ input_doesnt_ cause_frameskip ping test definitely needs renaming, because it no longer tests anything of the sort.
I'm weakly against the change to dispatch multiple events in a single process_ and_maybe_ send_event( ). Your comment is incorrect - there were no races: if consume() didn't read all the events from the fd then it would remain readable and we'd return to the dispatcher and immediately get called again.
When client-driven dispatch is available clients are going to expect to get a single event out of a single dispatch call.
**** So: ****
*) Rename or remove AndroidInputRec eiverSetup. slow_raw_ input_doesnt_ cause_frameskip ping and_maybe_ send_event( )
*) Don't loop in process_
Optional: and_maybe_ send_event( )? I'm pretty sure it is now always going to send an event. eiver?
*) Maybe rename process_
*) Test that you get at most one event sent per dispatch() on the AndroidInputRec