| Summary: | SDL_WaitEvent() polls | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Eero Tamminen <eerott> |
| Component: | events | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | icculus, rose.garcia-eggl2fk |
| Version: | 1.2.7 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Attachments: |
Block without polling in SDL_WaitEvent() patch.
ryan's patch for 1.2.10 ryan's patch for 1.2.11 ryan's patch for 1.2.12 ryan's patch for 1.2.13 ryan's patch for 1.2.14 ryan's patch for 1.2.15 |
||
We'd need to change the video backends to optionally block in PumpEvents() without returning immediately. This gets a little stickier when you want joystick events, too, though, since they go through a different path in both SDL and most OSes. I'll look at the former here. --ryan. Created attachment 176 [details]
Block without polling in SDL_WaitEvent() patch.
Here's a patch that removes polling from SDL_WaitEvent() when possible, including support in a surprisingly large percentage of the platform-specific backends. All the Unixy things that fall into a select() call (including X11 and fbcon) are supported.
Some notes:
- Existing behaviour remains (poll,sleep,poll,sleep) for backends that can't supply a non-polling mechanism. An internal interface changed, but besides updating the function signatures, code can just do what it did before and it gets handled properly.
- If there's a joystick detected, polling is used for everything (since we can't block in two different places). I don't have a good solution for this. At the app level, you can either unplug all your joysticks, or call SDL_Init() without SDL_INIT_JOYSTICK (or SDL_INIT_EVERYTHING). Eventually we may change this to at least only resort to polling when a stick is opened as opposed to detected.
- Enabling key repeat turns on polling while a key is pressed down (can't block in PumpEvents if this is to trigger reliably). It's off by default.
- Don't use SDL_INIT_EVENTTHREAD. You probably aren't anyhow. That still polls in all cases, at least for now, since I haven't checked all the corner cases.
Apply this patch to Subversion.
--ryan.
Tossing bug to Sam for approval on the patch. --ryan. After consideration, I'm going to flag this bug as WONTFIX, since I don't think such a big change with this many caveats should be made to the 1.2 branch at this point, but we can still point people to this bug if they want to use the patch in a custom SDL on an embedded device. Sam, please feel free to reopen the bug (and apply the patch to Subversion) if you disagree. --ryan. (In reply to comment #4) > After consideration, I'm going to flag this bug as WONTFIX, since > I don't think such a big change with this many caveats should be made > to the 1.2 branch at this point, Is this going to be considered for some later SDL version? > but we can still point people to this bug if they want to use the > patch in a custom SDL on an embedded device. Even people using laptops and desktop machines can be nowadays be interested about something like this... (In reply to comment #5) >> After consideration, I'm going to flag this bug as WONTFIX, since >> I don't think such a big change with this many caveats should be made >> to the 1.2 branch at this point, > > Is this going to be considered for some later SDL version? > > > but we can still point people to this bug if they want to use the > > patch in a custom SDL on an embedded device. > > Even people using laptops and desktop machines can be nowadays be > interested about something like this... Ping... It's three years from WONTFIXing this for 1.2.7 and two years from my above comment. This isn't fixed e.g. in current SDL v1.2.13 in Debian. Is it ever going to be? (In reply to comment #6) > Ping... It's three years from WONTFIXing this for 1.2.7 and two years from my > above comment. This isn't fixed e.g. in current SDL v1.2.13 in Debian. Is it > ever going to be? No, my WONTFIX stands. Debian (etc) can feel free to ship with the patch attached to this bug, but we've decided not to make this change for SDL 1.2. --ryan. Created attachment 4649 [details]
ryan's patch for 1.2.10
Created attachment 4650 [details]
ryan's patch for 1.2.11
Created attachment 4651 [details]
ryan's patch for 1.2.12
Created attachment 4652 [details]
ryan's patch for 1.2.13
Created attachment 4653 [details]
ryan's patch for 1.2.14
Created attachment 4654 [details]
ryan's patch for 1.2.15
i forward-ported ryan's patch to all SDL 1.2 releases past the patch creation date. however since 1.2.12 2 platforms have been removed and 2 (or more added), those are not covered. from 1.2.12 release notes: Support for AmigaOS has been removed from the main SDL code. Support for Nokia 9210 "EPOC" driver has been removed from the main SDL code. Unofficial support for the S60/SymbianOS platform has been added. Unofficial support for the Nintendo DS platform has been added. i hope this helps when porting this crucial feature to SDL2. |
SDL version: - I've got SDL version v1.2.7, but I've understood that the bug is also in the v1.2.8 How to repeat: - Run a program that sits in a loop waiting SDL_WaitEvent() call to end - Attach to the process with Gdb to see that the SDL_WaitEvent() function call is really blocking the program while SDL doesn't receive events - continue the process and attach strace to it: strace -tt -p <program PID> Expected outcome: - SDL sits in a select() until it receives an event Actual outcome: ----------- 20:03:56.145652 select(4, [3], NULL, NULL, {0, 0}) = 0 (Timeout) 20:03:56.145972 select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout) 20:03:56.156151 select(4, [3], NULL, NULL, {0, 0}) = 0 (Timeout) 20:03:56.156423 select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout) ... ----------- SDL polls between these two select calls constantly several times a second. Effect of the bug: - On a mobile device the CPU cannot sleep because the process isn't idle and SDL drains the device battery (while the SDL application would be otherwise idle) On a mobile device this kind of bugs are "must fix" things...