(a) Done.
(b) Done.
(c) Not done.
(d) Done instead of (c).
(e) Done.
(f) Done.
(g) Done.
(h) Done.
(i) Not done but should be.
(j) Done.

I will be off-line for a week and a half, starting in about ten minutes.

John F. Fay
-----Original Message-----
From: Fay John F Contr AAC/WMG
Sent: Monday, September 13, 2004 2:55 PM
To: ''
Subject: More proposed "freeglut" changes


        In the quest for an improved "freeglut", I would like to propose the following.  I got a lot of this from comparing "freeglut" with OpenGLUT a few weeks ago.

(a) In the "freeglut_geometry.c" file, I suggest that we check for zero "slices" and "stacks" arguments before dividing by them.  This would prevent the application from terminating on error.  GLUT calls "gluSphere" and "gluCylinder" for the appropriate shapes; with MSVC at least these do not terminate on error with zeroes for the number of slices and stacks.  For the torus GLUT does not check for division by zero and so does terminate on error; thus the suggested change would bring "freeglut" more in line with GLUT in the case of spheres, cones, and cylinders and would make its behavior diverge from that of GLUT in the case of the torus.

(b) Also in "freeglut_geometry.c", I propose to move the tetrahedron corner coordinates out of their respective functions and make them static in the file.  This will allow us to avoid defining them in two places.  We already do this with other shapes.

(c) In "freeglut_font.c", in the "fghFontByID" and "fghStrokeByID" functions, the code calls "fgError" and terminates on error if an unrecognized ID is passed in.  It has been suggested that the font handling be modified so that if the font ID is not recognized, the code take it as a pointer to an application-supplied font structure.  How do people feel about doing this?  I remember that there was quite a discussion of this earlier (pre 2.0.0 release) and we did not want to break drop-in compatibility with GLUT.  Should we just make a note to do this for 3.0.0?

(d) As an alternative to (c), perhaps the code could print a warning ("fgWarning" instead of "fgError") and continue execution.  The text would not be printed in the window (and there would be a warning message in the main window), but the application would not terminate on error.  GLUT's behavior here is ambiguous:  for Windows it flags a fatal error but for X it seems to behave as in (c) above and take the font handle as a pointer to a font structure.  Changing the "fgError" to "fgWarning" will not break compatibility unless the application is depending on "freeglut" giving it a quick exit under these circumstances.  And that I have a hard time imagining.

(e) There is a bit of slight streamlining that we can do in the "glutBitmapString" and corresponding "Length" and "Stroke" functions by changing "c" from in integer to a character and incrementing "string" to move down the string instead of incrementing "c".

(f) In "freeglut_init.c" on line 67 the "KeyRepeat" field of "fgState" is initialized to GL_TRUE; in "fgDeinitialize" on line 271 or so of the same file it is re-initialized to GL_FALSE.  The two should match; which value do we want?

(g) While I'm about it, "freeglut_init.c" has some extraneous parentheses on lines 233 and 239 that may as well be removed.

(h) I propose to extend "glutInitDisplayString" to support "win32pfd" (the present string "win32pdf" is a typo), "borderless", and the English spellings of "grey" and "colour".  I would keep all the presently supported strings.  The changes are fairly simple to make.  Does anybody have a heartburn with this?

(i) In the file "freeglut_joystick.c", the function "fghJoystickParseElement" seems to be completely unused.  Would anybody object to my removing it?

(j) In "freeglut_main.c", the functions "fghReshapeWindowByHandle" and "fghRedrawWindowByHandle" immediately recover the window pointer from the handle which is passed in from the calling function.  In each case, the calling function has the window pointer and finds the handle to pass into the function.  I propose to make life a bit more efficient by passing in the window pointer directly.

        There's more, but this is plenty for one e-mail.  Let me know what you think.

John F. Fay