Working on GLFW multi-window support...

Out of a basic need for more than one window, I felt compelled to add support to GLFW. I am now running into a problem, I cant debug the lib in its current configuration. Something is wrong, and I cant tell what it is at this moment.

Is there a way to make a MSVC++ or DevC++ debug lib without too much trouble?


Sorry for the absence of GLFW development lately. There are many things going on right besides GLFW, so it will have to wait some more before some big changes come along. Rest assured that multi window support in GLFW 3.x will be very neat, and fits nicely with the GLFW multi threading capabilities. Anyway, it’s all in my head for now…

Now, to answer your question: I am positive that you can modify the MSVC and/or MinGW makefiles and add a debug flag to the command list.

For MinGW/DevC++:

In lib\win32\Makefile.win32.mgw, change

CFLAGS = -c -I. -I… -Wall -Os
CFLAGS = -c -I. -I… -Wall -Os -g


CFLAGS_SPEED = -c -I. -I… -Wall -O3 -ffast-math
CFLAGS_SPEED = -c -I. -I… -Wall -O3 -ffast-math -g


In lib\win32\Makefile.win32.msvc, change

CFLAGS = /nologo /c /O1sgiy /Gs /W3 /I. /I…
CFLAGS = /nologo /c /O1sgiy /Gs /W3 /I. /I… /Yd


CFLAGS_SPEED = /nologo /c /O2tgiy /Gs /W3 /I. /I…
CFLAGS_SPEED = /nologo /c /O2tgiy /Gs /W3 /I. /I… /Yd

At least I think that should do the trick…

Ah, just to relate to you how I did it, I am threading “window numbers” thru the lib. I return a “window number” from the OpenWindow function. That number relates to the index of the lib’s global array of _glfwWin structure pointers. I created 50 elements in that array, and dynamically assign windows to the array when a window is opened. I know, a static array is cheesy, but I don’t think Im (or anybody else is) going to use more than fifty OpenGL windows in their app.

I am eager to see your multi window mod, but if I get done with this one, I’ll send you what I have. As far as I am concerned, its just a hack, no thread protections or anything like that.

I think your hack will suffice for prototype development until “the real thing” is done. GLFW v3.x will have implemented multiple window support as follows:

  1. OpenWindow returns a window ID (or 0 for failure) -> new functions: glfwBindWindow() and glfwMakeCurrent()

  2. Each GLFW window function will detect which thread is current, and which window is current for the calling thread, and operate on that window. That’s how GLFW will be 100% thread safe. (pthread_getspecific() and TlsGetValue() are the keys here)

  3. Each thread has its own list of windows, basically a linked list starting in each thread’s thread struct. No limit to the number of windows.

  4. Every thread that has an opened window has to call glfwPollEvents(), and glfwPollEvents() will be thread aware, so that it will only process events (and call callback functions etc) for windows that are owned by the calling thread.

  5. OpenWindow hints, which are presently stored in a global struct, will be stored in the thread struct. That way glfwOpenWindowHint() will only affect windows that are opened by the same thread.

…probably some other things too, which I have forgotten right now.

All in all, it means that the API (from a users point of view) will not change much from the current implementation. Properly written GLFW programs will probably compile and run with GLFW 3.x without any changes.