nigels-com
commented
5 years ago I'd be happy to see a FAQ added. Pull requests welcome.
In my opinion Apple GLUT is a better experience on Mac than FreeGLUT. But yes, Apple seem quite determined to remove GLUT support, at some point in the future.
I'm using Glui for an openGL based scientific app. It started as a proof of concept, before I created an iOS version that would get a native UI. Glui has so far stuck with the desktop app and worked well enough to not get switched out. Helps cover OSX, Ubuntu, Debian - even Raspberry Pixel.
So on Mac OS (Darwin), if one compiles against GLUT (Apple's supplied framework, via <GLUT/glut.h>) one suffers a million cuts by deprecation, essentially begging coder to stop. The general guideline is GLUT bad (obsolete), Freeglut good (maintained and API compatible).
So one heeds warnings, and starts to compile against <GL/freeglut.h> and with alternate linkage i.e. dropping '-framework GLUT' (for -lglut), with a -L to a lib directory of wherever you built freeglut, or a standard location if getting freeglut via a packager like homebrew.
But in doing so the app subtly acquires a dependency on XQuartz. This is OK'ish, until one finds that standard glut API calls may cause X errors, where they do not on Linux. I even submitted a bug here
Not an XServer fault per se, but a window manager one. But that's an aside, it is broken (out of the box) where Linux is not.
So now I compile against freeglut headers (one might alternatively turn off the deprecation errors -Wno-deprecated-declarations as I've seen done in a Glui make too) but I actually 'link' against Apple's Glut framework again. Bugs gone. For as long as that Glut remains available.
OK more Glui pertinent, as I sat coding with my hot aluminium case laptop degrading my reproductive capacity, I didn't realise that my GLUI_Master.set_glutIdleFunc( idle ) with nanosleep, was really just a kludge, addressing OSX freeglut CPU usage that was initially at 39% with no sleep call, down to 10% and finally 6% with larger nanosec values. But with a slightly laggy UI as a result. It's not always obvious when or where such a problem creeps in, when one is focused on new code.
Going back to linking with GLUT framework, XCode tells me that the app uses 0% CPU at idle. Of course it's OSX WindowServer that's now warming my lap, but at least windowserver is around 3% and cooler, with my Glui app running. And luckily for my lap, I'd already had kids.
The Glui source has warnings that it may not play with Freeglut, but as a library one might expect users to treat it as a black box plugin, and so get into trouble as above.
Not sure if this was covered elsewhere, it certainly isn't anywhere prominent. If I saw a Glui FAQ, I would certainly add it there. FAQ!?