GLUT is great! but -- how to break the message loop?

Anyone of you guys know if one can gain access to the device and rendering contexts when setting up a window in GLFW or CPW? I am trying to setup an application in which I generate a supersampled image in the background (At like 8x supersampling), then in a separate context I want to place a sample of the hidden buffer downsampled at the machines native resolution?

Originally posted by jmathies:
[b] doubtful. glut is dead. the author hasn’t
released a new version in years, and
the source is not open source. there
are a number of replacements, but none
of these have the breadth of support
glut does… yet.

Take a look at:

Cpw: http://www.mathies.com/cpw/ (Win32)
GLFW: http://hem.passagen.se/opengl/glfw/ (X11, Win32)

Regards,
Jim[/b]

Just use the Glutidle function. It is topologically equivalent to busting out of the loop.

Rationalle:

  1. If you are using GLUT your program is a temporary hack anyway.

  2. Therefore using glutidle function and not worrying about doing anything after glutMainLoop is fine.

  3. Event driven programming is a completely different paradigm than sequential programming; it is not at all uncommon to have to give up control for good (c.f. XtAppMainLoop )

Originally posted by FogAudio:
Anyone of you guys know if one can gain access to the device and rendering contexts when setting up a window in GLFW or CPW?

In GLFW you can’t. Well, you could, in an undocumented, unportable way: since you link statically to GLFW, you get acess to all the global variables used internally by GLFW. For instance, you can access the GLFW rendering context with the variable _glfwWin.RC, but that requires that you extract the definition of the _glfwWin struct from “internal.h” in the lib\win32 directory of the GLFW source distribution.

In other words, not a nice solution. Since the GLFW API is designed to be portable, things that are wgl/glX specific are kept hidden away from the user.

If you can think of a portable solution to this problem, I would happily include the functionality in GLFW in the future.

Actually, I think that access to the device and rendering contexts isn’t necessarily needed. Rather it would be very useful to simply have some methods that could make a certain instantiation current. That way one could flip between contexts very easily. Obviously then in creating each instance of a window (or buffer, or any context) a handle would have to be returned which is specific to that instance. That way when a glfwMakeCurrent(hVisible) like call is made you may provide the “handle” (or identifier-obviously it doesn’t need to be device context handle itself). I’m sorry if I don’t have all of the details down on how to do this since I am fairly new to this stuff. But hopefully I am not too off track.

But I think it would look something like this

myVisibleWindow = glfwOpenWindow(…);
myHiddenWindow = glfwOpenBuffer(…);
myVisibleWindow2 = glfwOpenWindow(…);
//etc…

glfwMakeCurrent(myHiddenWindow);
// do some rendering
glDoSomething(…);
glDoSomethingElse(…); …
// maybe sample my hidden buffer

glfwMakeCurrent(myVisibleWindow);
// do some other stuff
etc.

This way device and rendering contexts are really never exposed to the user at all. Also if they are creating a simple application with a single window then they could ignore the handle from the OpenWindow() command since most likely you would want it to switch to that context when it is created. Therefore they wouldn’t have to ever make it current since it would be by default.

Originally posted by marcus256:
[b] In GLFW you can’t. Well, you could, in an undocumented, unportable way: since you link statically to GLFW, you get acess to all the global variables used internally by GLFW. For instance, you can access the GLFW rendering context with the variable _glfwWin.RC, but that requires that you extract the definition of the _glfwWin struct from “internal.h” in the lib\win32 directory of the GLFW source distribution.

In other words, not a nice solution. Since the GLFW API is designed to be portable, things that are wgl/glX specific are kept hidden away from the user.

If you can think of a portable solution to this problem, I would happily include the functionality in GLFW in the future.

[/b]

This is something I have planned for a long time now. It doesn’t fit 100% with the current code layout of GLFW, but I’m trying to get GLFW in that direction. Multiple windows is always a problem, especially when we’re dealing with fullscreen windows, multiple threads, event polling etc, so I have some work ahead before I can get there.

When you say “buffer”, do you mean a pbuffer?

API-wise, the changes are not huge. As you said, if only one window is opened, one would not have to care about the handle (so basically it would be source code dompatible with the present API). All window management functions (glfwSetWindowTitle etc) should act on the window that was most recently selected with a suitible function (e.g. glfwSelectWindow). I’m just not sure what happens with event polling when an app has opened several windows (this should be portable - work under both X11 and Windows), which is one of the reasons that I have not done so much about it yet.

[This message has been edited by marcus256 (edited 05-15-2002).]

Hmmm…Yeah I am not so sure about event polling. I think you could provide a different WinProc (or X11 equivalent) callback for each window or context. In fact, you may want to provide an optional argument when registering a callback for resize, key and mouse events. Or it could just use the current state (whatever context is current) when registering these callbacks. There again, current apps would still be correct if you had the context argument be optional. I am not sure as to the implications of having multiple windows (i.e. threads) trigger events back to your manager. I presume that you would have to provide conditionals to make sure each RenderScene() like function for any given context is atomic. I am not sure whether your own glfwCreateCond() can be used to do this synchronization but it does seem like a natural fit? How different this needs to be done in UNIX??? Again I plead ignorance.

Originally posted by marcus256:
[b]This is something I have planned for a long time now. It doesn’t fit 100% with the current code layout of GLFW, but I’m trying to get GLFW in that direction. Multiple windows is always a problem, especially when we’re dealing with fullscreen windows, multiple threads, event polling etc, so I have some work ahead before I can get there.

When you say “buffer”, do you mean a pbuffer?

API-wise, the changes are not huge. As you said, if only one window is opened, one would not have to care about the handle (so basically it would be source code dompatible with the present API). All window management functions (glfwSetWindowTitle etc) should act on the window that was most recently selected with a suitible function (e.g. glfwSelectWindow). I’m just not sure what happens with event polling when an app has opened several windows (this should be portable - work under both X11 and Windows), which is one of the reasons that I have not done so much about it yet.

[This message has been edited by marcus256 (edited 05-15-2002).][/b]

I have some pretty good ideas about how to do it now (I did some thinking yesterday). I think the key is to make everything context sensitive (including the callback functions and the key/mouse/window state queries). I may also end up requiring that the programmer only deals with events, input and window management from the main thread (I heard that under MacOS X the event loop could only be called from the main thread - and GLFW should be portable).

The biggest problem as I see it is fullscreen windows. I may limit GLFW so that a fullscreen window can only be opened when no other widnows are opened, and no “normal” windows can be opened when a fullscreen window is opened. Another solution may be to always iconify fullscreen windows when another window is opened/activated/selected (which is basically already done in the present version of GLFW).

As for buffers, I think simply adding a third window “mode” option to glfwOpenWindow should be enough:

glfwOpenWindow( …, GLFW_BUFFER );

As far as fullscreen goes I think the near future will include dual displays or more for gamers and consumers. Especially in a couple years or so with the advent of Microsoft Windows Longwood (or whatever it is called). In that case I could see opening more than 1 full screen. But I haven’t researched that much into how multipipe displays are configured yet (so this is just hypothetical). Princeton’s Wall project has an awfully interesting site on building super-res displays via multipipes. I downloaded a ton of research papers on the subject about a month ago but thus far have only skimmed a couple.

I will keep an eye on the GLFW webpage over the coming months to see how this multicontext version turns out. In the meantime I may access those variables which you eluded to a few posts ago (your global device contexts) and see if I can scrap together what I need for now. Oh and specifying an optional argument (GLFW_BUFFER) in glfwOpenWindow() works for me!

Thanks for all the feedback, Marcus. It’s really fun interacting with such a power programmer like yourself. It makes me really appreciate this newsgroup knowing that system architects are monitoring and active in it!

No, it’s not the equivalent of busting the loop. It is in no way the equivalent of busting the loop.

Originally posted by FogAudio:
Actually, I think that access to the device and rendering contexts isn’t necessarily needed. Rather it would be very useful to simply have some methods that could make a certain instantiation current. That way one could flip between contexts very easily. Obviously then in creating each instance of a window (or buffer, or any context) a handle would have to be returned which is specific to that instance. That way when a glfwMakeCurrent(hVisible) like call
<snip>

Hey Fog,

Cpw supports multiple contexts. The library
is multi-state in design, so there are no
global variables. Everything related to a
state is stored in a state structure, which
you can access.

For example:

Single State Example:

pCpw cpw;                                                   
cpwInitContext( &cpw );                                     
..                                                          
                                             
cpwFreeContext( &cpw );
exit(0);

Multistate Example:
pCpw cpw1;
pCpw cpw2;

cpwInitContext( &cpw1 );                                    
cpwInitContext( &cpw2 );                                    
                                             
cpwDisplayCallback( cpw1, app1_displayCallback );           
cpwDisplayCallback( cpw2, app2_displayCallback );           
                                             
cpwCreateWindowEx( cpw1, "App1 Win1", 100, 100, 300, 300 );
cpwCreateWindowEx( cpw1, "App1 Win2", 120, 120, 300, 300 );
cpwCreateWindowEx( cpw2, "App2 Win1", 200, 200, 300, 300 );
cpwCreateWindowEx( cpw2, "App2 Win2", 220, 220, 300, 300 );

..
while ( running ) {
    cpwMainLoopUpdate( cpw1, 1 );
    cpwMainLoopUpdate( cpw2, 1 );
}
..                     

cpwFreeContext( &cpw1 );
cpwFreeContext( &cpw2 );
exit(0);

You can access the rendering contexts through
the cpw state structure if needed. FYI this
library is currently supported on Win32.

Regards,
Jim

If you want to do all this stuff, if you want to break out of the loop, etc…

Why are you programming in GLUT? GLUT is a toolkit for rapid prototyping, not a thourough windowing mechanism.

Write in Win32…
I don’t get it.

Now if the issue is portability, that is a different story but GLUT is still not the answer.

Originally posted by nickels:
[b]If you want to do all this stuff, if you want to break out of the loop, etc…

Why are you programming in GLUT? GLUT is a toolkit for rapid prototyping, not a thourough windowing mechanism.
[/b]

Yet people use GLUT as if it is a “thourough windowing” framework… hence all the traffic about it, and hence the newer solutions out there that do supply a solid solution for this kind of use.

Regards,
Jim

[This message has been edited by jmathies (edited 05-17-2002).]

I’m now using FLTK - the fast light toolkit - http://www.fltk.org
it has opengl support too, a glut emulation layer and avaiable on many platforms.
i just wrote last week a little tetris game using fltk. look here: http://www.andre-krause.net/tetris/coloris_ver_01_small.gif
http://www.andre-krause.net/tetris/index.html

[This message has been edited by herc (edited 05-20-2002).]