It is often the case that windowing libraries tend to result in large,
bulky programs because a large measure of ``dynamically dead'' code is
linked into the programs because it can not be determined at link time
that the program will never require (that is, execute) the code. A
consideration (not a primary one though) in GLUT's API design is make
the API modular enough that programs using a limited subset of GLUT's
API can minimize the portion of the GLUT library implementation
required. This does assume the implementation of GLUT is structured to
take advantage of the API's modularity.

A good implementation can be structured so significant chunks of code
for color index colormap management, non-standard device support (Spaceball,
dial & button box, and tablet), overlay management, pop-up
menus, miscellaneous window management routines (pop, push, show, hide,
full-screen, iconify), geometric shape rendering, and font rendering
only need to be pulled into GLUT programs when the interface to this
functionality is explicitly used by the GLUT program.