GLUT on Snow Leopard

Hello everyone,

I can’t get my GLUT program to behave properly on MacOS 10.6. I seem to be having the same issue as this person:

http://svnstrk.blogspot.com/2009/11/os-x-snow-leopard-glut-problem.html

Quote:

“So recently I installed OS X Snow Leopard on my Macbook Pro after knowing the 10.6.2 solves the problem in Autodesk Maya. However, I forget to install XCode so I used XCode 3.1.2 and hell what did I find. All my GLUT based program is a total mess. First of all, it does not compile. So I downloaded version 3.2 and it compiled. But then, the next problem is the screen did not refreshed. Means that I have to switch windows to ‘force’ GLUT to redraw. I am not really sure what happened, but when I updated my mac, the problems suddenly vanished (forever I hope).”

This is a new machine which came with 10.6, but I used the data transfer assistant from a 10.5 machine, so the old version of xcode was installed. I installed the new one and now I have the issue that my GLUT program does not redraw as described above. I installed the XCode update with the OSX Software Updater, didn’t help. I uninstalled XCode and reinstalled it clean, didn’t help either.

I’d be grateful for any advice on how to get GLUT to work with 10.6. I really can’t find any other help on the subject.

Thanks!

Do the old GLUT examples still build and run correctly for you?
/Developer/Examples/OpenGL/GLUT/…

I don’t have that OpenGL directory, should I? I chose the full xcode install. I don’t use any of the OSX tools and pretty much just treat it like a normal UNIX system, make and gcc etc.

Huh. I guess Xcode stopped installing the examples sometime.

Try downloading and building GLUTBasics:
http://developer.apple.com/mac/library/samplecode/GLUTBasics/index.html

That should work (drag the object to rotate it.)

From the description you gave, the problem in your app is likely a mismatch between the GLUT window creation (using GLUT_DOUBLE, or not) and the swap (using glutSwapBuffers or glFlush).

The glut code worked fine in 10.5 and windows. Also it seems the author of the blog fixed his issue by updating xcode and not changing his program. I tried both single and double buffered output to diagnose this issue.

From what I can tell after a quick look at the GLUTBasic program it shows the same issue. Its display callback is not called unless it asks for a redraw or the window size changes etc.

btw, I tried to compile Free GLUT in the meantime, gave up after fixing the most obvious build errors.

Well, I guess GLUT is just a lost cause on Snow Leopard. Pretty lame. The trunk of GLFW seems to work on 10.6, wrote my own font rendering to replace GLUTs. Waste of time, but it works.

GLUT is working fine for me in Snow Leopard-- used daily.

Can you clarify your expectations, about " Its display callback is not called unless it asks for a redraw or the window size changes etc."

Of course, the display callback is not going to be called unless needed-- that’s as intended. Are you referring to glutIdleFunc or something else?

I use GLUT under 10.6, too, with no problems. And GLUT’s source code is available, so I can’t see any problem.

Me too. Just installed Xcode, included the framework, and it just works fine.

Same problem existed for me on a previously (10.5) working piece of GLUT code. GLUT in 10.6.3/10.6.4 would only refresh if there was a UI-related event pending in the main thread’s event queue.

I checked it out in GDB and it seem’s Apple’s internals for GLUT have changed on the event cycle (for some/all cases of glutCheckLoop() and glutMainLoop()). It now spontaneously suspends at

“BlockUntilNextEventMatchingListInMode”

until the main event loop posts a valid UI event. Curiously, a valid UI event seems to unblock > 1 glutCheckLoop() cycles, but then it invariably hangs again at this same point internally.

Easy workaround (though ugly as sin): just post a non-consequential event to the main event queue prior to each call to glutCheckLoop(). This will guarantee that GLUT doesn’t hang and your GLUT app will continue to work correctly on 10.6.x until Apple figures this out.

I used a wheel event with 0 pixel movement, as in:

for (;:wink: {

    // 
    // Post non-consequential UI event to prevent GLUT from blocking on event list in Snow Leopard
    // 

    CGEventRef				mouseWheelEv=CGEventCreateScrollWheelEvent(NULL,kCGScrollEventUnitPixel,1,(int32_t) 0);
    CGEventPostToPSN(&gGLUTAppPSN,mouseWheelEv);
    CFRelease(mouseWheelEv); 

    // 
    // .. now call glutCheckLoop and it won't hang in SL
    // 

    glutCheckLoop();

}

Just be sure to fetch your process PSN beforehand (I did when I called glutInit()), as in:

...

if (GetCurrentProcess(&gGLUTAppPSN) == noErr) {
    glutInit(&argc,argv); 
}

and you’re rocking again.

Happy GL’ing…

I have the same problem. With my own glut program and both GLUTSurfaceTexture and GLUTBasics sample I have to move my window before rendering starts.

I just removed Xcode entirely and reinstalled (3.2.3) and the problem is still there. It would be nice to hear from you that doesn’t experience this problem what Xcode version you are running.

I don’t experience this.

I just downloaded and built GLUTBasics, with 10.6.4 + Xcode 3.2.2, on a MacBookPro with GeForce 330, and it works fine.

I have no issues with GLUT on Snow Leopard. It sounds like you just need to call glutPostRedisplay() from within a timer loop.

If you don’t have that timer setup I believe GLUT will only call your display function when it starts or needs to redisplay (resize, redraw).

I’ve just posted a object-oriented wrapper around GLUT that provides a display() method. It will call your display() method around 60FPS using a high-performance timer. The code will run on both Mac/Windows.

Blog post: http://paulsolt.com/2010/08/glut-object-oriented-framework-on-github/
Source: http://github.com/PaulSolt/GLUT-Object-Oriented-Framework

It’s an easy to get a graphics window, you can subclass and provide application specific logic in the display method:


        #include "GlutFramework.h"
	using namespace glutFramework;
	GlutFramework framework;
 	framework.startFramework();

-Paul Solt

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.