# glfwOpenWindowHint() problem

**URL:** <https://discourse.glfw.org/t/glfwopenwindowhint-problem/300>\
**Category:** support\
**Created:** [September 27, 2010, 5:16pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300 "2010-09-27T17:16:33Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 27, 2010, 5:16pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/1 "2010-09-27T17:16:33Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Monday, September 27, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#3c0e):

The above function causes GLFW to fail to open a window a lot of the time for  
me.

I’m using:  
MinGW  
Windows Vista  
nVidia Quadro NVS 140M with latest drivers (8.17.12.5896)  
GLFW latest precompiled release (statically linked)

I can get OpenGL 3.3 with my card, and by default GLFW will use this version.  
But if I explicitly request this version via the above function, it fails  
intermittently (I haven’t quite managed to reproduce this reliably yet…)

What I CAN reproduce is GLFW’s failure to open a window if I request a  
forward-compatibility context or a core profile.

The following code I hashed up illustrates my problem. Below is the code and  
it’s output on my machine. Any help would be appreciated.

[http://pastebin.com/u7Cz6RPT](http://pastebin.com/u7Cz6RPT)  
[http://pastebin.com/cW2qUSEB](http://pastebin.com/cW2qUSEB)

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 27, 2010, 6:19pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/2 "2010-09-27T18:19:40Z")

</div>

**[elmindreda](https://sourceforge.net/u/elmindreda/)** wrote on [Monday, September 27, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#4d83):

Your test program is broken. glfwOpenWindow resets all window hints to their  
default values. You should also not close windows using glfwTerminate and  
glfwInit. glfwCloseWindow is sufficient. Here’s an updated version:

[http://pastebin.com/HNAi4apa](http://pastebin.com/HNAi4apa)

You also don’t need to call atexit, as glfwInit does this for you (GLFW  
Reference Manual §3.1.1).

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 28, 2010, 11:07am UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/3 "2010-09-28T11:07:51Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Tuesday, September 28, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#9064):

Wow, I messed that up then. Your revised program gives me the following  
output, which is much closer to what I’d expect (stdout followed by stderr):  
[http://pastebin.com/tSXrRE8d](http://pastebin.com/tSXrRE8d)

To cut a long story short, GLFW seems to have been choking on the bit depths I  
requested via glfwOpenWindow. I noticed your code passes in 0 for every one,  
while I was passing 8. The former works but the latter does not.

Thanks a lot for your help!

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 28, 2010, 11:33am UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/4 "2010-09-28T11:33:02Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Tuesday, September 28, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#18b3):

Actually, I spoke too soon. The window now opens fine, but  
glfwGetWindowParam() tells me I don’t actually have a forward compatibility  
context OR the core profile: [http://pastebin.com/p5BXjW7b](http://pastebin.com/p5BXjW7b)

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 28, 2010, 1:12pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/5 "2010-09-28T13:12:30Z")

</div>

**[elmindreda](https://sourceforge.net/u/elmindreda/)** wrote on [Tuesday, September 28, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#4167):

Hmm, 8 is an odd number for depth buffer bit count (which is usually 24 or  
32), although it should still work using 8. If it doesn’t, that’s a bug in  
GLFW.

The latter problem definitely is a bug in GLFW. It seems we’re not setting  
those two window params. I’m adding it to 2.7.1. Thanks.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 28, 2010, 3:23pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/6 "2010-09-28T15:23:35Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Tuesday, September 28, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#1503):

A final note: drawing a rotating pyramid (using  
[http://pastebin.com/3DQ2EmCV)](http://pastebin.com/3DQ2EmCV%29) produces a  
blank screen, if I explicitly requested a GL 3.3 or 3.2 context via  
glfwOpenWindowHint().  
If I request GL 3.0 or 3.1 , GLFW reports using those versions and the pyramid  
appears.  
If I request any GL version lower than 3.0 , GLFW reports using GL 3.3 but the  
pyramid STILL appears.  
If I don’t request a specific GL version at all, GLFW again reports using GL  
3.3 and the pyramid appears.

You’ll notice I’m deliberately using deprecated functions when drawing the  
pyramid.  
So to put it another way, those deprecated functions fail to work if I  
explicitly request a newer OpenGL version, REGARDLESS of what version GLFW  
actually gives me - it can give me a 3.3 context in which the pyramid still  
draws, so long as I haven’t specifically asked for that context.  
All this in spite of the fact I don’t have forward-compatibility or the core  
profile as above.

Thanks a lot for your interest in all of this…

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 28, 2010, 3:57pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/7 "2010-09-28T15:57:06Z")

</div>

**[elmindreda](https://sourceforge.net/u/elmindreda/)** wrote on [Tuesday, September 28, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#e20b):

The default isn’t to use the compatibility profile; the default is to let the  
implementation decide. On my machine, requesting an OpenGL 3.2 context  
(sorry, don’t have 3.3 here) gives me a 3.2 core profile context. Try  
explicitly requesting the compatibility profile.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 28, 2010, 5:12pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/8 "2010-09-28T17:12:35Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Tuesday, September 28, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#7479):

You’re right, explicitly requesting the compatibility profile causes the  
pyramid to appear with GL 3.3 / 3.2 contexts.  
By default, it seems my machine uses the core profile whenever I request a  
recent enough GL version.  
However, if I request an older GL version (\< 3.0) or don’t explicitly  
request one at all, I get a 3.3 context with the compatibility profile.  
I should mention that in all cases, glfwGetWindowParam() returns 0 when I  
ask for the currently used profile.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 28, 2010, 5:36pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/9 "2010-09-28T17:36:34Z")

</div>

**[elmindreda](https://sourceforge.net/u/elmindreda/)** wrote on [Tuesday, September 28, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#d292):

Tha’ts the same creation behaviour I have here, with an nVidia card on Linux.

As for glfwGetWindowParam, I completely forgot to add read-back of the profile  
and forward-compat params. That’s why they are and always will be zero on 2.7.  
Sorry about that. Fixing it in 2.7.1.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 28, 2010, 6:09pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/10 "2010-09-28T18:09:10Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Tuesday, September 28, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#f389):

Ah, so there’s a good chance my previous efforts WERE setting profile and  
forward-compat modes, but glfwGetWindowParam() won’t be able to confirm it  
to me? That’s much less of an issue, given I can guess what’s going on fairly  
well with the pyramid thing.

Thanks for your help.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 28, 2010, 9:17pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/11 "2010-09-28T21:17:13Z")

</div>

**[elmindreda](https://sourceforge.net/u/elmindreda/)** wrote on [Tuesday, September 28, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#7c4f):

Yes, setting the hints works as expected in 2.7. You can verify this using the  
version test, which in 2.7 doesn’t rely on window parameters.

I believe I’ve fixed this bug in Subversion trunk now, if you want to try it  
out.

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 29, 2010, 11:14am UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/12 "2010-09-29T11:14:15Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Wednesday, September 29, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#c50b):

I should say this is literally my first attempt at building other peoples’  
code, but I gave it a go.  
I got the tarball from  
[here](http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/) and compiled with  
ming32-make.exe using compile.bat .  
It produced the following output & errors:  
A quick search through the tarball suggests those symbols are only defined in  
version.c , which I believe is just test code.  
win32\platform.h DOES include symbols which are very similar:  
WGL\_CONTEXT\_ \* \_ARB as opposed to GL\_CONTEXT\_ \*  
and win32\win32\_window.c uses those. I’m in the process of switching the  
symbols in window.c that MinGW chokes on to see what happens…

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 29, 2010, 11:14am UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/13 "2010-09-29T11:14:41Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Wednesday, September 29, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#ee3e):

Whoops, forgot to add the output & errors:  
[http://pastebin.com/M1agGtDV](http://pastebin.com/M1agGtDV)

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 29, 2010, 11:42am UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/14 "2010-09-29T11:42:06Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Wednesday, September 29, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#a96c):

With the above symbol substitutions, GLFW compiles fine. The bundled example  
and test programs work, and it seems I can now retrieve profile and forward-  
compat status in my own projects via glfwGetWindowParam().  
For your information, my modified lib\windows.c file is here (only a few  
lines are different):  
[http://pastebin.com/9YK0YYsQ](http://pastebin.com/9YK0YYsQ)

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex035/uploads/glfw/original/1X/b8cdefe6b61b8d5aee6c43b2c56e9cf5eabecfe4.svg) [@system](https://discourse.glfw.org/u/system)\
**Post date:** [September 29, 2010, 12:04pm UTC](https://discourse.glfw.org/t/glfwopenwindowhint-problem/300/15 "2010-09-29T12:04:49Z")

</div>

**[mgcode](https://sourceforge.net/u/mgcode/)** wrote on [Wednesday, September 29, 2010](https://sourceforge.net/p/glfw/discussion/247562/thread/7a5b00d3/#5387):

Ha, spoke too soon. GLFW now reports forward compatibility as enabled,  
regardless of what I request via glOpenWindowHint() . The core/compat  
profiles work fine though.