@dircategory The Algorithmic Language Scheme
@direntry
-* Figl: (figl.info). An OpenGL interface for Guile.
+* Figl: (figl.info). Guile Scheme interface to the OpenGL API.
@end direntry
@titlepage
* API Conventions:: General conventions used by the Figl APIs.
-* GL:: A Scheme interface to OpenGL.
+* GL:: A Scheme interface to the OpenGL API.
* GLU:: The GL Utility library.
* GLX:: Using OpenGL with the X Window System.
* GLUT:: The GL Utility Toolkit.
Figl is the Foreign Interface to GL: an OpenGL binding for Guile.
-OpenGL is a family of APIs and layers. The following chapters discuss
-the parts of OpenGL and how they are bound by Figl.
+In addition to the OpenGL API, Figl also provides access to related
+libraries and toolkits such as GLU, GLX, and GLUT. The following
+chapters discuss the parts of OpenGL and how they are bound by Figl.
But before that, some notes on the Figl binding as a whole.
@node About Figl
@section About Figl
-Figl is a @dfn{foreign} interface to OpenGL because it uses the
-dynamic @dfn{foreign function interface} provided by Guile 2.0,
+Figl is a @dfn{foreign} interface to the OpenGL API because it uses
+the dynamic @dfn{foreign function interface} provided by Guile 2.0,
providing access to OpenGL without any C code at all. In fact, much
of Figl (and this manual) is automatically generated from upstream API
specifications and documentation.
Our strategy has been to separate the binding into low-level and
high-level pieces.
-The low-level bindings correspond exactly with the GL specification,
+The low-level bindings correspond exactly with the OpenGL specification,
and are well-documented. However, these interfaces are not so nice to
use from Scheme; output arguments have to be allocated by the caller,
and there is only the most basic level of type checking, and no sanity
The high-level bindings are currently a work in progress, and are
being manually written. They intend to be a complete interface to the
-GL, without the need to use the low-level bindings. However, the
-low-level bindings will always be available for you to use if needed,
-and have the advantage that their behavior is better documented and
-specified by OpenGL itself.
+OpenGL API, without the need to use the low-level bindings. However,
+the low-level bindings will always be available for you to use if
+needed, and have the advantage that their behavior is better
+documented and specified by OpenGL itself.
Low-level bindings are accessed by loading the @code{(figl
@var{module} low-level)}, for example via:
@node About OpenGL
@section About OpenGL
-OpenGL is a standard API for drawing three-dimensional graphics. From
-its origin in Silicon Graphics's workstations the early 1990s, today
-it has become ubiquitous, with implementations on mobile phones,
-televisions, tablets, desktops, and even web browsers.
+The OpenGL API is a standard interface for drawing three-dimensional
+graphics. From its origin in Silicon Graphics's workstations the
+early 1990s, today it has become ubiquitous, with implementations on
+mobile phones, televisions, tablets, desktops, and even web browsers.
OpenGL has been able to achieve such widespread adoption not just
because it co-evolved with powerful graphics hardware, but also
-- William Gibson
@end quotation
-Before interfaces end up in core OpenGL, the are usually present as
-vendor-specific or candidate extensions. Indeed, the making of an
-OpenGL standard these days seems to be a matter of simply collecting a
-set of mature extensions and making them coherent.
+Before interfaces end up in the core OpenGL API, the are usually
+present as vendor-specific or candidate extensions. Indeed, the
+making of an OpenGL standard these days seems to be a matter of simply
+collecting a set of mature extensions and making them coherent.
Figl doesn't currently provide specific interfaces for extensions.
Perhaps it should, but that's a lot of work that we haven't had time