Expose SDL_MAX_QUEUED_EVENTS to users

[namandixit]

Would it be possible to export the SDL_MAX_QUEUED_EVENTS macro in SDL_events.h? I understand that it will become part of the ABI contract, but it'll be useful for programs to be able to record events in a pre-allocated static buffer (especially games that use the callback-based main) without having to put a potentially heavyweight malloc in the event loop which will add latency to the event processing.

[slouken]

No, you'll almost never reach the limit of events. If you do, that means you're getting events at a high rate and not emptying the queue regularly.

If you want more efficient event processing, it's better to do something like this:

{
    SDL_Event events[128];
    int count;

    SDL_PumpEvents();
    while ((count = SDL_PeepEvents(events, SDL_arraysize(events), SDL_GETEVENT, SDL_EVENT_FIRST, SDL_EVENT_LAST)) > 0) {
        for (int i = 0; i < count; ++i) {
            // Handle events[i]
        }
    }
}

[namandixit]

No, you'll almost never reach the limit of events.

@slouken Is this true for all platforms and situations? For example, if a user types a long string on an IME keyboard, can we be sure that that string will not be delivered as a long series of events -- one for each codepoint in the string?

If you want more efficient event processing, it's better to do something like this:

How do SDL_PumpEvents/SDL_PeepEvents interact with the SDL_AppEvent? I can't find documentation for it.

[slouken]

No, you'll almost never reach the limit of events.

@slouken Is this true for all platforms and situations? For example, if a user types a long string on an IME keyboard, can we be sure that that string will not be delivered as a long series of events -- one for each codepoint in the string?

Yes, you can verify this by looking at the code or testing it yourself.

How do SDL_PumpEvents/SDL_PeepEvents interact with the SDL_AppEvent? I can't find documentation for it.

Oh, this approach won't work for SDL_AppEvent(), if you're using the callbacks you don't need to worry about it. Your function will get called once for each event.

[namandixit]

Yes, you can verify this by looking at the code or testing it yourself.

I can see that SDL won't do it, but I don't see how we can be sure that the OS or a third-party IME won't do it (now or after some update, intentionally or as a bug). This is the degenerate behaviour I am worried about.

Your function will get called once for each event.

This is what I was referring to in the issue. The fact that we can't query total number of events means that we have to now call malloc inside the event callback, thus adding unnecessary latency.

It would be one thing if we could instruct SDL to not send any more events but call AppIterate (perhaps by returning some special value from AppEvent), but since we can't do that either, getting a static bound on maximum number of events seems to be to be the best idea.

[slouken]

I'm not sure I understand. Why would you have to call malloc() inside the AppIterate function?

In any case, we're not going to expose this value. You can assume it, if you like, since it's not likely to change.

[namandixit]

I'm not sure I understand. Why would you have to call malloc() inside the AppIterate function?

Inside AppEvent, since we don't have a user-facing max bound on events.

In any case, we're not going to expose this value.

Okay.