OpenGLEAN User Support
Home page | Introduction | Documentation | Files | Examples | Proposals | Authors | Links

OpenGLEAN Development
Summary | CVS | (discussion via home page) | (contact via home page) | (suggestion box) | License | Todo | Bugs

OpenGLEAN Project

0.6 development

OpenGLEAN - A leaner GLUT.


Offscreen rendering to a texture using OpenGLEAN


OpenGLEAN is an open source project to enhance the GLUT API. OpenGLEAN uses a codebase inherited from:


Part of the GLUT family

Why OpenGLEAN?

In 2003, a serious, crashing bug was found in Mark Kilgard's old GLUT. It was the only serious bug that this author has ever confirmed in GLUT. When running a debugger (gdb) on the application, things happened that made no sense. In particular, variables changed around in ways that should not have been possible. This was probably something of an optical illusion caused by compiler optimisation, but: The crash was real; the bug was ellusive; technically, GLUT's license didn't allow fixing it.

There was an alternative library with a goal of being compatible: freeglut. freeglut had its own warts, but none as bizarre as the GLUT bug. This author submitted some requests and patches to the freeglut project, and was invited to be a freeglut developer.

For some time, this author worked on freeglut, but also developed a desire to add certain features that went beyond freeglut's scope. freeglut is geared only to be a drop-in for the last released version of Mark Kilgard's GLUT. Growth and innovation are very limited in freeglut.

So the presure began to mount almost immediately for a fork of freeglut.

Eventually, another freeglut author contacted this author suggesting that it was time to fork freeglut. This had not been discussed between them previously, but came to a head over deeply held convictions about the desirability of a more featureful GLUT like library. freeglut would never grow in the required way. Thus OpenGLUT was born. They added features that freeglut would not support, such as offscreen rendering, menu windows, etc. The OpenGLUT project documented the library as a major effort. They fixed many bugs. Most of OpenGLUT's changes, other than the documentation (the single biggest effort) and the new features, were either lifted verbatim back into freeglut (e.g., the vastly improved bitmapped font handling) or were re-implemented in freeglut (closely modeled on the trail-blazing that OpenGLUT had done.

Meanwhile, it was apparent that OpenGLUT was not going to be moved into one of the main directions that this author had always wanted. Namely, removal of "deadwood" features. E.g., there is no completely backwards-compatible way to "fix" gamemode. One or two functions had been obsoleted by Mark Kilgard's original GLUT in the 1990s while Mark was still active. Other problem features were ill-defined across multiple implementations. Then again, this author felt that if OpenGLUT were going to move beyond the realm of a toolkit for simple demonstration programs, and into the realm of a serious portability toolkit, OpenGLUT should define a clear focus for the library, and features that did not fit into that clear focus should be migrated out of the library.

The whole idea of trimming dead or obsolete features from OpenGLUT had been key to OpenGLUT's founding, since it was one of the main objectives of 50% of the founders. Unfortunately, the OpenGLUT team could never reach any consensus about actually removing dead features, and it was long past time to begin that process---a process that should have been done shortly after OpenGLUT began building.

So, taking his work up again, this author is finally beginning the work he stated he wanted to do when OpenGLUT was founded. OpenGLEAN, destined to be a leaner member of the GLUT family, was born in late 2004.

In some ways, it is unfortunate that the work has not continued under one library. However, from the other side, it is fortunate that two other libraries have been able to share in part of the work put into the codebase now called OpenGLEAN. Also, as freeglut chiefly aims at being a drop-in for already-compiled software, freeglut really should not change the library API number, which constrains it to be as compatible as possible (no function removals, however disagreeable the API may have been; even feature additions are dubious).

Remember: Forking is good in many cases. It means that there is energy and passion finding an outlet that did not exist before, for whatever reason. Energy and passion is what open source thrives on. Whether there was a way to uncork that energy and passion without forking, a fork only happens if pressure is forced to intolerable levels. (This must be said, since some push a propoganda that "forking is always wrong" or "forking is always a mistake". It may not always be right, but to categorically say that it is always wrong is either to over-simplify or to actively disemble. For OpenGLUT and OpenGLEAN, the fork was forced and was the best thing that those doing the fork could have done.)


As of this writing, code is updated relative to both OpenGLUT and freeglut (early 2005). Except for one long-obsolete feature of old GLUT, this means that the union of features of both libraries (OpenGLUT and freeglut) are contained within OpenGLEAN. But no library except for GLUT itself is a complete implementation of Mark Kilgard's original GLUT.

General features of the GLUT family:

Within the family derived from freeglut, these features are possessed:

Shared with OpenGLUT are these features:

Additional OpenGLEAN features:


Some of these plans are intended to make OpenGLEAN a more stable API and implementation. Anyone who has administrated a UNIX-like system and dealt (seriously) with security issues in libraries such as PNG, JPEG, and TIFF (each of which has, if memory serves, had advisories just in the year 2004) will appreciate the value of symbol privacy and reduced dependancies---and won't sneer at faster builds. Developers with an eye to the future should appreciate that OpenGLEAN intends to break historic compatibility early: Through the fire once, quick and clean. This is seen as preferable to late and slowly. Once the pruning is done, the API should be stable against further losses for a long time to come. Features will be added, but retaining backwards compatibility will be a goal, and at the same time buggy "fluff" won't be an issue.

In addition, the OpenGLUT API proposals are still on the table: OpenGLEAN API Proposals.

Other OpenGLUT ideas being considered for OpenGLEAN; see also the other sub-projects:


Menu window using OpenGLEAN

Using OpenGLEAN


Detailed API and example documentation is available from the SourceForge project interface for OpenGLEAN.


Currently, development releases are made from time to time. See the OpenGLEAN file download section, e.g., at the OpenGLEAN SourceForge interface.


The current development version of OpenGLEAN is source-compatible with the GLUT API, but not binary-compatible.

OpenGLEAN 1.0 will neither be a proper superset nor subset of GLUT 3.x.

The motivation for the OpenGLEAN API is to make OpenGL based development easy, productive and reliable. We would welcome feedback in relation to API proposals, results with using OpenGLEAN in applications, and feature requests or proposals. There may well be functionality in your own application that could serve a broader long-term purpose.


The core OpenGLEAN is maintained in a private CVS tree; the satellite libraries are being set up in their own CVS trees, however, on the OpenGLEAN SourceForge CVS server. The core is not presently available for anoncvs, cvsweb, or nightly tarballs; it may be migrated to a SourceForge CVS tree, however.

There are various reasons for using a private tree. One was the desire to be able to track back through OpenGLUT history. Another is that at project inception, OpenGLEAN was wavering between being a private project and a public project; with neither a SourceForge project nor a domain name in the public eye, a private tree was created. Now, there is enough history in the private tree that migrating to a public tree may be problematic, even though some of the value of the original private tree has been undermined by rearrangments of the code relative to OpenGLUT. Logo Supported in part by

Generated on Fri Sep 16 20:15:18 2005 for OpenGLEAN by doxygen 1.4.3
The OpenGLEAN project is hosted by and SourceForge.