idle not at 0%

SDL Development
1

There’s no problem but I noticed something and I’m curious if anyone knows why.

I took a look at htop on linux to see how much CPU my program was using when it was not drawing on screen and it was 0.7% (less than 1 percent). I put a sdl delay of 10k and it went to 0 and I was wondering why. I ran this code under perf record and it claimed touching the stack while entering and existing the app iterator took the time. That’s a few magnitudes less than 0.1% worth of a cpu per second. The code below draws 5 times until it idles and I ran it for a few minutes

I’m assuming there’s a large margin of error. Using main instead of callbacks gives the same results. It could be a just on my machine thing

// gcc -O2 -march=native cpuTest.c -lSDL3 -o cpuTest && ./cpuTest
#define SDL_MAIN_USE_CALLBACKS 1
#include <SDL3/SDL.h>
#include <SDL3/SDL_main.h>
#include <stdio.h>

SDL_Window*window;
SDL_Renderer*renderer;
SDL_AppResult SDL_AppInit(void**appstate, int argc, char*argv[])
{
	SDL_Init(SDL_INIT_VIDEO | SDL_INIT_EVENTS);
	if (!SDL_CreateWindowAndRenderer("Test", 640, 480, SDL_WINDOW_RESIZABLE|SDL_WINDOW_MAXIMIZED|SDL_WINDOW_HIGH_PIXEL_DENSITY, &window, &renderer)) {
		return SDL_APP_FAILURE;
	}
	SDL_SetRenderVSync(renderer, 1);
	return SDL_APP_CONTINUE;
}
SDL_AppResult SDL_AppEvent(void*appstate, SDL_Event*event) {
	if (event->type == SDL_EVENT_QUIT) { return SDL_APP_SUCCESS; }
	if (event->type == SDL_EVENT_KEY_DOWN) {
		if (event->key.key == SDLK_ESCAPE)
			return SDL_APP_SUCCESS;
	}
	return SDL_APP_CONTINUE;
}

int renderAmount = 5;
SDL_AppResult SDL_AppIterate(void*appstate)
{
	if (renderAmount) {
		SDL_SetRenderDrawColorFloat(renderer, 0.1, 0.1, 0.1, 1);
		SDL_RenderClear(renderer);
		SDL_RenderPresent(renderer);
		renderAmount--;
	}
	SDL_Delay(10);
	return SDL_APP_CONTINUE;
}
void SDL_AppQuit(void *appstate, SDL_AppResult result)
{
}
2

At a 10 milisecond delay, you are still escaping and returning from the function about 100 times per second, and each time the thread/program is halted the CPU saves the thread’s state so that it can be properly woken up later. Then the interrupt routine gets called when the delay timer fires, and the operating system has to figure out the details about what program is being returned, and system calls are a bit of heavy lifting. It’s a bit more intensive than just a single function being called and released.

Try a wait-loop like this:

int renderAmount = 5;
SDL_AppResult SDL_AppIterate(void*appstate)
{
	if (renderAmount) {
		SDL_SetRenderDrawColorFloat(renderer, 0.1, 0.1, 0.1, 1);
		SDL_RenderClear(renderer);
		SDL_RenderPresent(renderer);
		renderAmount--;
	}
	else
	{
		while(SDL_WaitEvent(NULL) == 0)
		{
			// SDL_WaitEvent() does not consume the event if the argument is NULL
			// It can sometimes break out without an event, which is why it's in a loop
			// This cannot be used with Emscripten, as Emscripten will think the program froze.
		}
	}
	SDL_Delay(10);
	return SDL_APP_CONTINUE;
}

Your CPU usage should be

3

Try a wait-loop like this: … SDL_WaitEvent … This cannot be used with Emscripten

I guess I could if I want 0% cpu. I only support desktop OSes atm
Would this do anything weird when using callbacks? Does SDL expect all events to be through AppEvent when I’m not using main?

4

Those are good questions.

Yes, the events should only be processed in the SDL_AppEvent function. We are just peeking at the event queue in the wait-loop to see if an event exists.

I don’t have enough experience with the SDL_App callback API to give a full guarantee that all events will wake the wait-loop. Since SDL_AppEvent can run concurrently to SDL_AppIterate, it’s possible that SDL_AppEvent will process an event before the wait-loop wakes the SDL_AppIterate function. The callback API is not mentioned in the SDL_WaitEvent docs either. I would need to look at the source code in hopes that the designers worked that out.

For now I’m going to take back my recommendation of a wait-loop being used when using the SDL Callback API, just because I am lacking in solid information on the topic, my apologies.

5

It was a fine suggestion, I peeked at the source a few months ago and it seemed fine to handle events in random order (on linux at least). I just wasn’t sure about mobile and I knew not for wasm.

I still don’t like the idea of app event happening in the middle of my app iterate which the docs suggest can happen. I put code to report an error and exit if it ever happens. I do not want to deal with that

6

The docs for SDL_AppIterate says:

This function may get called concurrently with SDL_AppEvent() for events not pushed on the main thread.

And the docs for SDL_AppEvent says:

SDL itself will push events to the queue on the main thread.

So if I understand this correctly, SDL_AppIterate and SDL_AppEvent won’t run concurrently as long as you don’t push any events yourself from other threads.

7

I do push events from 1 other thread. I guess I should start a thread