We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4541 - SDL_ANDROID_BLOCK_ON_PAUSE should be removed, instead please fix SDL_WaitEvent
Summary: SDL_ANDROID_BLOCK_ON_PAUSE should be removed, instead please fix SDL_WaitEvent
Status: NEW
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: 2.0.9
Hardware: x86_64 Android (All)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-07 12:45 UTC by Ellie
Modified: 2019-04-23 03:51 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ellie 2019-03-07 12:45:08 UTC 
SDL_ANDROID_BLOCK_ON_PAUSE somewhat looks like a hack around the fact that SDL_WaitEvent wastes battery due to not being implemented in a smart way. This hack breaks the semantics of SDL_PollEvent in surprising and not-cross-platform ways.

I suggest the following changes to fix this:

- remove SDL_ANDROID_BLOCK_ON_PAUSE / default it to 0
- SDL_WaitEvent should be fixed at least on Android to actually block

Apps can then choose to use SDL_WaitEvent if in the background if they want this blocking behavior. This solves: 1. the weird unexpected API semantics difference, 2. that this cannot be chosen at runtime without recompiling SDL2, 3. that there's this weird duplication of functionality which SDL_WaitEvent already should provide
Comment 1 Sylvain 2019-04-02 07:20:50 UTC 
SDL_WaitEvent is actually doing SDL_PollEvent + SDL_Delay: 

https://hg.libsdl.org/SDL/file/d5b4d374a312/src/events/SDL_events.c#l697
Comment 2 Ellie 2019-04-02 09:20:20 UTC 
Yes and that makes SDL_WaitEvent somewhat useless in terms of battery saving, even though at a first glance it would be the obvious choice! So fixing it to be truly blocking would make it the obvious usable choice and make that on pause "feature" completely unnecessary
Comment 3 Sam Lantinga 2019-04-17 02:53:42 UTC 
SDL_WaitEvent() can't block because events come from multiple sources that can't be aggregated in a cross-platform way.
Comment 4 Ellie 2019-04-17 07:00:33 UTC 
Isn't the point of SDL2 to solve these issues between different platforms? If that currently doesn't work with various internal sources, then it sounds a little like that should be refactored.

Also it would already help a lot if at least it worked properly on mobile platforms, if getting this to work on all platforms is too much work.

I can tell you, I have lurked in freenode/irc and even familiar SDL2 users are always surprised that SDL_WaitEvent is close to a busy loop rather than a proper block-until-event. It's really not expected behavior, and it would IMHO in the long term make much more sense to see how to fix it rather than add hacks like SDL_ANDROID_BLOCK_ON_PAUSE to work around this - at least if we're talking purely from a sane API design angle.

Of course if this is way too complicated to be feasible then maybe it's not worth it. But I can't judge that, I'm not familiar with the affected code
Comment 5 Sam Lantinga 2019-04-23 03:51:41 UTC 
Yes, it is too complicated to be feasible, in my opinion. However, I'll leave this bug open in case someone wants to contribute a patch they feel is valuable.