SDL2: lag with SDL_GetTicks

Hello Everyone,

During the development of my project, i have noticed some “lags” when using SDL_GetTicks().
At a repeated interval of 3 seconds, there is a lag of 40 ms.
Here after is a simple code triggering the observed lag:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sdl.h>

int main(int argc, char argv[])
* myWindow = NULL;
SDL_Event myEvent;
SDL_bool keepOnTesting = SDL_TRUE;
Uint32 lastTick = 0, temp = 0, lagTime = 0;



while (keepOnTesting)

   case SDL_QUIT:
       keepOnTesting = SDL_FALSE;
  temp = SDL_GetTicks();
  if ((temp - lastTick) > 1)
      SDL_Log("Lag time: %d, Lag interval:%d, Lag value: %d",temp,temp-lagTime,temp-lastTick);
      lagTime = temp;
  lastTick = temp;


The result of SDL_Log can be seen in the uploaded screen capture

Is it possible to get rid of this lag?


Do you mean that the lag is introduced via SDL_GetTicks() or that there is some lag in general?

Compiling your code and running it on my machines (both win10 and linux) does not result in the same. I assume you are on windows - are you sure your AV software/debugger or something else running on your machine isn’t causing this? Window resizes or movement can also be a cause.

Try SDL 2.0.8 to see if the situation improves, if so then try this patch for 2.0.9:

Apparently in 2.0.9 joystick querying can cause a hiccup on some setups every 3 seconds. I was getting 100ms hiccups without this patch.

Hello mkalte and dafu, thank you for having taken the time trying to help me.

To answer the questions of mkalte, I’m working on W10. I’ve closed the AV software but it did not help.
The problem is no related to the SDL_GetTicks() function in itself, but the SDL_GetTicks() function allowed me to highlight the problem.

I’ve modified my code to remove the SDL_PollEvent function (just looping and closing the window after 20s, not monitoring any event in the system) and when I did that, the lag disappeared. I did also observed the same lag problem with the SDL_WaitEvent() function.

I think now that I’m experiencing the bug reported by dafu as following the answer of dafu, i have disabled all joystick events (a total of 7 different events ranging from SDL_JOYAXISMOTION to SDL_JOYDEVICEREMOVED) with the SDL_EventState(event type, SDL_IGNORE) function and it solved the lag problem.

As I don’t plan using the Joystick in my application, I don’t need reverting back to SDL 2.0.8 nor I need applying the given patch.

Your answers helped me to solve my problem. I’m very grateful for that and I thank both of you a lot.

I am concerned by that bug report:

Why does SDL_JoystickUpdate() call hidEnumerate every three seconds?

Even if joysticks are enabled, there should be no need for SDL to re-enumerate at runtime during SDL_JoystickUpdate(), causing potential slowdown.

The user has to take care of that anyways using SDL_JoystickOpen().

This behaviour was a bug.
This “enumerate every 3 seconds” thing is implemented to support hotplugging (=> detecting new devices or if existent ones have been unplugged) - but it should only be used in case the operating system can’t tell you about those events.
Not sure which operating systems support/don’t support sending you plug/unplug-events, but Windows certainly does support it, so it shouldn’t happen (on Windows it should only be used if telling Windows to send those events failed).

The bug in 2.0.9 is basically that if you don’t activate joysticks via SDL_Init(), the internal flag for “operating system will send events” is not set, and because of that the frequent enumerations are done (the fix was to not do those enumerations at all if joysticks aren’t enabled).
So one possible workaround (if you want to use unpatched 2.0.9) is to pass SDL_INIT_JOYSTICK to SDL_Init(), even if you don’t otherwise use/support joysticks. (I think doing this shouldn’t “hurt” or cause additional events, because you should only get input events from joysticks if you have enabled a particular joystick with SDL_JoystickOpen() or SDL_GameControllerOpen().)

This is fixed for SDL 2.0.10, and you can grab a snapshot with the fix here: