GLFW window opening extremely slow?

OpenGL
1

Okay, so I’m trying to start a project using GLFW. But every time I open a window, it at first appears to have frozen (white window, “waiting” cursor, wont accept any input whatsoever), but after about 30-60 seconds it creates the window that it’s supposed to. I’ve tried this with 3 or 4 different programs and the result is always the same. Am I setting up my project wrong or something?

I’m using Visual Studio 2010 Ultimate. Here’s my source code:

#define GLEW_STATIC

#include "GL/glew.h"
#include "GL/wglew.h"
#include "GL/glfw.h"

#include <stdio.h>

#pragma comment (lib, "glfw.lib")
#pragma comment (lib, "opengl32.lib")
#pragma comment (lib, "glu32.lib")

int main(int argc, char** args)
{
	bool running = true;
	glfwInit();
	glewInit();
	glfwOpenWindow(640, 480, 8, 8, 8, 8, 24, 0, GLFW_WINDOW);
	glClearColor(0.5, 0.5, 1.0, 1.0);
	while (running)
	{
		 /////////////////////
		// Begin Main Loop //
		glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

		glfwSwapBuffers();

		running = !glfwGetKey(GLFW_KEY_ESC) && glfwGetWindowParam(GLFW_OPENED);
	}

	glfwTerminate();
	return 0;
}

It’s not the cleanest code, but like I said I’ve tried a few different simple programs and the result is the same - a 30 second - minute long delay until the window opens.

2

I’m using GLFW on Windows 7 with ATI card compiling with minGW and I’ve not seen this, but I did have a problem with fullscreen taking over a minute to start up. A couple of driver updates later and the problem disappeared. Does fullscreen take the same time?

So all I can suggest is check you’ve got the latest drivers. Only other thing that stands out is glewInit. I’ve not used that so don’t know if it could be an issue.

You could also try using freeGlut to see what it does.

3

I’ve tried commenting out all glew-related code, but nothing changes. I don’t want to use glut because it doesn’t support the features I want - GLFW does everything I need it to (except disabling the windows DWM, but that’s only one thing, and I can code that in myself).

I’m using an NVidia card on windows 7, and I have the latest driver version (280.26). Fullscreen gives the same delay.

4

Do you know what the exact function is that’s getting the slowdown? Can you step through your main function and see which function is taking a long time?

Also, is this a release build?

5

The function that’s taking forever is glwOpenWindow(). I tried release, debug, and even a build I compiled myself, same result.

6

And when you break the debug build in the middle the 60 seconds, can you see where inside glwOpenWindow() you fall into ?

BTW, can you describe your hardware setup, os version, driver version ?

7

The point was to see if this is something specific to GLFW.

You could build a debug version with a static GLFW and step through it’s code to see exactly what’s going on. Also, you could use gDEBugger (now free) and break on every openGL call to see which one is taking the time (http://www.gremedy.com/).

8

Okay, I tried opening a glut window with similar problems. Rather than displaying a frozen window, however, glut simply takes it’s minute before it opens any window.

9

So, did you debug into the library? Where was it stalled?

10

Couldn’t figure out how ._.

11

Isn’t it Visual studio that actually spends the time? Have you tried simply to run the generated executable outside of VS?
I’m pretty sure your issue has nothing to do with GLUT or GLFW.

12

If this is only stalling while running under visual studio, inspect the internal Visual studio output window (not the console window etc) and see if it is stalling on loading a dll.

eg. “Loaded ‘C:\Windows\SysWOW64
tdll.dll’”

If that is the case, google for the message - I recall at my previous company similar symptoms when somehow the nt dll symbols were installed and they took 1min+ to load every time they went to debug.

13

It stalls when I run the application outside of visual studio, both release and debug builds.

14

Okay found it! I tried opening a window in pure Win32, to the same delay. After putting a bunch of break points in, I pinpointed the problem at ChoosePixelFormat()

PIXELFORMATDESCRIPTOR pfd = {
				sizeof(PIXELFORMATDESCRIPTOR),
				1,
				PFD_DRAW_TO_WINDOW |
				PFD_SUPPORT_OPENGL |
				PFD_DOUBLEBUFFER,
				PFD_TYPE_RGBA,
				32,
				0, 0, 0, 0, 0, 0,
				0, 0,
				0, 0, 0, 0, 0,
				16,
				0,
				0,
				0,
				0,
				0, 0, 0	};

			int PixFormat = ChoosePixelFormat(gHdc, &pfd);

Any idea why that’s taking so long?

EDIT:

I tried skipping ChoosePixelFormat entirely by just specifying “7” (which is what ChoosePixelFormat returns for me), but I’m getting the same delay! The delay moved to SetPixelFormat, which was previously instant! What the heck is going on?

I paused it in the middle of the delay, and the name of the item on the call stack it’s on is “ntdll.dll!776200ed()”. I opened the dissasembly and it says "776200ED add esp,4 " is where it’s at.

Does anyone know about this? I’m stumped…

15

The problem is solved. For some reason, when your executable is named “game.exe”, ChoosePixelFormat() looks for another exe, over and over and over again. Yeah. Don’t try to figure out the logic behind that one.

16

Those executables sound like some relics from Red Alert 2 :
http://komku.blogspot.com/2007/07/red-alert-2-and-yuri-revenge-in-windows.html

Are you using Nvidia hardware ? Maybe it is time their driver would enhance whatever strange optimization/workaround they put in place for that game …