Startup/Execution Delay with SDL3 Main Callbacks

SDL Development
1

I wrote an application that has two modes: a GUI mode and a command line mode. The general idea is that when I call the app without command line arguments, I launch the GUI mode, otherwise the command line mode. Launching the app in GUI mode triggers all the typical SDL stuff (like SDL_init etc.) and creates an application window while launching it in command line mode does none of that and just calls my app’s core functionality that doesn’t need a window.

Now I noticed that the command line mode has gained some significant delay during launch, basically stalling for like 1 or 2 seconds before printing anything to stdout. Something must be happening before my own code gets even called. I suspect that SDL does something before my own code gets called but the only way for that to be true would be that the SDL3 main callbacks I use are somehow involved.

My code is basically something like this:

SDL_AppResult SDL_AppInit(void**, int argc, char* argv[]) {
  if (argc > 1) {
    return run_cmdl_mode(argc, argv);
  } else {
    return run_gui();
  }
}

where `run_cmdl_mode` returns SDL_APP_SUCCESS after executing, thus terminating the program and not letting SDL into its iterate state.

Does anybody know if there is something significant happening before my `SDL_AppInit` gets called? This is on Windows btw., haven’t tested other platforms.

Edit: Maybe I should mention that I compile SDL together with my app and link it statically.

Thank you!

Thomas

2

I wonder if it would be worth it to not use the SDL3 main callbacks to begin with, but instead write your own main() and event loop. It’s really not much code, and also I find that it helps the code organization, by pushing the UI code into its own “module”.

I use this pattern all the time in my own code, FWIW, where numerous cmdline options, such as --help, make it inappropriate to spin up a GUI. (Or a more extreme example, programs where the user can use options to request either a SDL-based GUI or a curses-based TUI.)

3

There is very little code that runs before SDL_AppInit(), mostly just command line parsing. Your best bet is to run under a debugger and break during the initial delay and see what it’s doing.

4

So I managed to test my tool under Linux now and cannot observe the delay there. It also seems to be absent when running it with a debugger attached from VS Code (under Windows). At this point I suspect some Windows antivirus scanner delaying the execution of my tool.