SDL_SendAppEvent and SDL_SendWindowEvent return a Boolean indicating whether the event was successfully posted or not, but this is ignored. Can I conclude that the “common reason for error” is not so common after all?
In SDL 1.2, the event queue was a static array of 128 items, which is generally way more than you need if you are draining the queue every frame and don’t push any events of your own, but would easily overflow outside of those parameters, or if an app did if (SDL_PollEvent(&e)) every frame instead of while (SDL_PollEvent(&e)).
In SDL 2, the queue grows dynamically, as a doubly-linked list, and has a hardcoded limit of 65535 items. Since the queue grows dynamically, the limit is only there to prevent unbounded allocation if an app has completely failed to deal with the event queue at all. But in normal use, it would be extremely unlikely that it would fail.
(we should at least assert in those internal calls, if we aren’t going to check the return code, but really…managing to overflow the event queue in SDL2 would suggest no one cares if the events make it there or not.)
Most helpful, thank you. I will probably leave my ‘retry’ code, because it does no harm, but it’s good to know that a queue overflow is very unlikely in normal circumstances. It would be nice if the documentation could be updated…
That would have saved me some grief. I accidentally left a SDL timer running whilst my app was backgrounded (on Android) with the result that the event queue filled after about five hours! The app then crashed on resume, I think because the full queue prevented SDL posting the appropriate messages.