Massive startup time difference between OpenGl window and non-OpenGl Window

Hi everybody!

I’m new to SDL (and its forum) and I’m really excited getting started here!

I noticed a pretty big difference in startup time comparing a normal window and a window tagged with SDL_WINDOW_OPENGL.

I created a super simple code that just starts a window and closes it when the event SDL_QUIT is polled.

The window starts immediately when the program starts.

When I change the window’s tag to SDL_WINDOW_OPENGL the program immediately starts to take a decent amount of time to start the window.

I tried creating and not creating the opengl context, I tried a number of opengl attributes (via SDL_GL_SetAttribute) and all of the results were the same.

I’d like to know if that is normal or if I’m doing something wrong.

Dan Zaidan

Hi Dan,

What operating system are you on?
What GPU and driver? What CPU?
How long is “a decent amount of time”?


Hi Daniel.

I should have included that info in the first place! :stuck_out_tongue:

I’m running a 64-bit Windows 10 on an i7 5820K @3.3GHz.
For the GPU, I have two GTX 780 (SLI) running the driver GeForce 382.05.

I’m compiling the code in Visual Studio (via command line). 64-bit target.
The project is linking with sdl2.lib and sdl2main.lib (and I have SDL2.dll in the exe directory).
All of them are the latest versions (I downloaded them yesterday!).
I’m running the optimized version of the code (-MT -nologo -Gm- -GR- -EHa- -O2 -fp:fast).

It takes 3 full seconds for the window to open when using Opengl. When not, it takes no time at all.

Dan Zaidan

Ok, I don’t think this is normal at all, but I don’t use Windows much
(and don’t have a machine with Win10 at all), so I can’t test it.
I hope someone with more Windows experience and a Win10 machine can help
figuring this out :slight_smile:


Thanks anyway, Daniel! o/

First thing I’d do is run it in the VS profiler ( ) to see what is happening during the 3 second delay. However, I’m not sure if the 2.0.5 release DLL will have debug info in the VS profiler.

It would probably also be worth checking out the latest source for SDL2 from HG (or download a snapshot from ) and profile one of the sample programs, testgl2.

Thanks, Eric! That sounds like a nice way to track down the problem. I’m gonna try that.

However I just found something out that might actually change the approach to the problem:
I copied the executable to 2 other computers and they didn’t have the 3 second delay!

So it’s probably something on the computer that might be conflicting with opengl. I have no idea what that might be. Is there anything I should look for in the computer?

Update: Tested on another computer and it was as slow as the first. The strange thing is that both computers that had the big startup speed problem have the faster hardware…

The VS profiler could probably help you track it down :slight_smile:
I’ve also heard good things about

A long startup delay is commonly caused by a virus scanner checking the executable. Windows Defender is particularly prone to doing this. It’s not obvious why selecting OpenGL would make a difference, but I’d still try whitelisting your app (or the entire directory) to see if it helps.

@rtrussell Yeah I thought it might be it. I added both the .exe and the directory to be excluded from Windows Defender (I don’t have any other anti-virus software) but nothing changed.

As for the profiling, I didn’t have much success with it (it’s the first time I use it):

Profiling started.
Profiling process ID 16768 (first).
Error deleting p:\noctus\build\first170723.etl and p:\noctus\build\first170723.kernel.etl output files: Could not find a part of the path ‘p:\noctus\build\first170723.etl’.
Profiler stopping.
Unknown output file name
Error starting data collection with a dedicated process C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Performance Tools\VSPerf.
PRF0025: No data was collected.
Profiling complete.

I’ll keep trying to profile the app. :stuck_out_tongue:

Edit: I should note that I don’t have an actual visual studio project. I just created a .cpp in a text editor and compiled it via command line.

Just to add some info, I tested on the drivers GeForce 382.05, 384.76 and 384.94; still the same result.

I made a small program that called opengl myself (without SDL) and the startup delay still happens.
I ran line by line in the code to see where is the problem and the result is strange: I posted about that here ->[day_235]_opengls_pixel_format_takes_a_long_time#12632

Could this maybe be related to this: ?

Ok, just checked the linked handmade thread, seems to be the same problem indeed!

Looks like a driver problem then, as it was a lot faster (but still kinda long) in 378.*

Thanks for linking the tweet here, Daniel!

Because of the “If NVIDIA folks following me want more info” part, I assume they are already aware of that.
It’s reassuring to know that the problem is widespread… :stuck_out_tongue:

mmozeiko just posted a great workaround that can decrease the lag to less than 50%!