pygame.event.wait always polls (3036) #1541
Description
Issue №3036 opened by mwcampbell at 2022-02-17 12:56:24
I studied the C source for pygame.event.wait, and it always polls for events, waking up every millisecond (or as frequently as the OS will allow) between polls. SDL can sometimes use the appropriate platform function to actually wait for an event. This has two somewhat paradoxical benefits:
- If the timeout isn't specified, or if it's long, the OS can actually put the process to sleep for long periods of time, saving power.
- On the other hand, if events are arriving in quick succession, but not all at once, the fixed delay between polls won't be a bottleneck. This will be important for any future implementation of accessibility (e.g. for screen readers) on Windows and Mac, since those platforms' accessibility APIs are based on request/response IPC where the requests must be handled by the OS event pumping mechanism, and a screen reader may have to send several requests in quick succession. IPC overhead is bad enough without adding a 1ms+ delay between round trips.
I don't know how to use the actual SDL_WaitEventTimeout function without breaking pygame's custom event filtering, so I'm just pointing out the issue here.
Comments
# # ankith26 commented at 2022-02-17 13:07:06
Nice catch! This is something I noticed myself sometime back, but I forgot about it.
Actually I made the change to use a custom waitevent implementation a while back, and now that I look back at it, I realise some of the stuff I added in event.c are rather inelegant, and I'm quite sure we can actually get back to using SDL_WaitEventTimeout, with some event filtering stuff done differently.
# # mwcampbell commented at 2022-02-23 21:34:33
@ankith26 I would like to personally pay you up to USD 500 to solve this. Please email me if you're interested. My email address is in my GitHub profile.
# # ankith26 commented at 2022-02-24 03:58:34
Whoa, thanks a lot for the generous offer! Honestly, 500 USD is too much to solve a single issue and I'm a volunteer :)
Besides I'm not the best person to be funding as there are many more pygame devs more experienced than myself. But if you are really keen in supporting pygame, the lead maintainer of pygame has a patreon here, this also helps with covering pygame website hosting costs
Regarding this issue, the only blocker is our custom WINDOWEVENT translation code, which needs to run from filter function after every event pump with SDL_FilterEvents. If this filtering happens in the main event filter, the WINDOWEVENTs are not available for internal SDL use. The solution here is to not do WINDOWEVENT filtering at all, and instead special-case window event handling in functions that convert SDL Events into pygame events. If we do things this way, we also need some changes in some event block/unblock mechanisms but that shouldn't be too hard.
# # mwcampbell commented at 2022-02-24 14:10:12
Well, I want to pay someone who deeply understand the relevant code to work on this specific problem, as it is impeding the work I plan to do on screen reader accessibility for Pygame, and there's no way I can work around it from outside the module. I could try fixing it myself, but that would be a suboptimal use of time, as I don't know this code nearly as well as you do. I realize, though, that accepting payment for one-off jobs from random people can be more trouble than it's worth. That's one reason why I set the offer as high as I did. Also, I recognize that an expert's time is worth a lot.
# # mwcampbell commented at 2022-02-24 14:33:35
I just discovered that the Ren'py engine, which is where I want to implement accessibility in the short term, is using its own implementation of the pygame API, pygame_sdl2. pygame_sdl2 doesn't have this problem with events. Since I already offered to pay for a solution to this issue, that offer still stands. But I don't actually need this fix in the short term.
# # ankith26 commented at 2022-02-24 14:53:54
Cool, renpy seems like it could work well for your usecase for now. I see renpy's event handling code is much simpler than pygames, but pygame_sdl2 would not be completely compatible with pygame2. The reason event.c is more complex at the moment is because pygame tries to make it harder for users to shoot themselves in the foot while dealing with events. Proxy events exist because posting SDL non-user events became problematic when user code expects they can fill in any attribute they want in the Event. Proxy events are also helpful with handling event blocking stuff correctly while posting SDL1 compatibility events. Also we export a slightly different WINDOWEVENT API than standard SDL2.
I want to further simplify event.c a bit and also fix this issue, and I think I could do it within a week.
Again, thanks for the generous offer, it is surprising and nice to hear that our work and time was valued so well :)