Todo List

The latest list is available at http://www.openglut.org/todo.html

Note:

New bug reports or suggestions should be directed to the bug or requested feature enhancement trackers at Sourceforge.

• Remove most of these to \todo, \bug, or \note annotations.

• In the Atlantis demo, under windows and with the task bar to the left of the screen, the GLUT window comes up in a position relative to the corner of the screen while the "freeglut" window comes up down and to the right of where it was the last time it was opened.

• In the Atlantis demo, if you stop the animation and move the mouse around with a menu open, the whales jiggle but don't circulate. My guess is that you need a way to redisplay the menu without forcing a redisplay from the application.

• In the Atlantis demo, if you bring up the menu in GLUT the animation stops; in freeglut the fish and whales wiggle without advancing. This may be another manifestation of (2).

• In the Atlantis demo modified to draw a solid torus instead of a mother whale, the torus is not shaded according to the lighting. This is true with both GLUT and freeglut. With freeglut, when you bring up a menu the shading used to turn on but doesn't any longer; with GLUT it never did and still does not. Interestingly, if you change to a teapot it is shaded, but other geometric shapes are not shaded.

• With the "bluepony" demo under Windows, if you reshape the window using the mouse, the scene does not redraw until you move it with a keypress (arrow key or space bar to start the animation). Check out the "CS_VREDRAW or CS_HREDRAW" sections in MSVC help for a pointer about this.

• If you compare the "bounce" demo with freeglut and GLUT, you see that the "freeglut" lights are larger and dimmer (and don't shine on the walls) than the GLUT lights.

• Large submenus in "freeglut" tend to cover their parent menus, making it difficult to get past them. This is visible in the "geoface" demo. In GLUT the menus can extend outside the window; "freeglut" should do the same thing.

• In the "gliq" demo, the cones forming the ends of the arrows in the "select board" are lighted differently in "freeglut" than they are in GLUT.

• The "fgCleanUpGlutsMess" function seems to duplicate the "fgDestroyStructure" or "fgDeinitialize" function and should probably be removed.

• The "freeglut_internal.h" file on lines 45ff defines or undefines "G_DISABLE_ASSERT" and "G_DISABLE_CHECKS" but these are never used. Shall we start using them or should we delete them?

• P-GUIDE apparently calls the get and set window size functions repeatedly. Each time it does, the window shrinks by 2 pixels in each direction.

• X support wrongly assumes exactly 3 mouse buttons.

• Indexed color mode might work, however I have not tested it yet. glutGetColor/glutSetColor is not implemented. Again, looks like a single Xlib call, but there might be some problems with the colormap access. Need to switch into indexed color mode some day and check it out (does Mesa 3.1 work with indexed color mode?)

• Overlays are not supported, but one of the GLUT conformance tests fails due to glutLayerGet( GLUT_NORMAL_DAMAGED ) returning FALSE when the window has actually been damaged.

• Does the init display string work?

• The visibility/window status function is a conceptual mess. I had to peer into the GLUT source code to see what actually happens inside. It helped me a bit, but still one of the visibility tests fails. This is probably the reason for which a window covered by enlightenment status bar is marked as hidden and does not get redrawn.

• GLX 1.3 spec states that glXChooseVisual() et consortes are deprecated. Should move to glXFBConfig. (No, should not. glXFBConfig[sic] does not exist on many systems. This is a terrible idea until the new function is actually available. Deprecation does not mean abandonment.)

• Need to investigate what happens when initial window position is set to (-1,-1). GLUT specification says, that the window positioning should be left to the window system. And I do not know how to force it do so...

• I was told it is wrong to have the redisplay forced in the main loop. Is that right? I am not aware of any place where it is forced, but it is certainly wrong to force it if there's no request from the client nor informing event from the OS.

• Some of the tests freeze because they do not generate the glutPostRedisplay() call every frame. Is this still a problem?

• Menus do not display in single-buffered windows, although they are active and the user can pick from them if he knows how to move the mouse exactly right. Fixed, I think.

• In the "boundary.c" demo in the "advanced" directory, if the outline rendering is turned on the menu background turns black.

• In the "comp.c" demo in the "advanced" directory, we find that we need a window to be defined before glutGet(GLUT_DISPLAY_MODE_POSSIBLE) can be called. GLUT does not have this restriction. Is this fixed?

• When you get around the requirement for an existing window in "comp.c", you find that "freeglut" renders the window differently from GLUT. For starters, "freeglut" looks like it is double-buffering while GLUT looks like it is single-buffering. In 'freeglut" the background is all black while in GLUT it starts black and turns white before your eyes.

• Running the "convolve" GLUT demo in the "advanced" directory (after fixing it so it doesn't terminate on error), I find that the "freeglut" version runs much more slowly than the GLUT version. I think this has to do with forcing redraws when the menu comes up.

• The "genmipmap" demo runs much more slowly in "freeglut" than in GLUT (try moving a window!) and flashes the texture over the whole window instead of just the part of the window where it finally settles down.

• We need to keep the "freeglut" structure current (including the GLUT action on window closure) after the last window closes. (Aleksandar Donev e-mail, 7/4/03, 5:00 PM). Is this fixed?

• The visibility callback is not invoked when minimizing a window. It should be.

• We should add a "glutExit" call to the interface. Also a "glutGet" to tell whether it has been initialized properly. And have "freeglut" call "glutExit" before it calls exit().

• Remove (post-1.0) the glutVisibilityFunc(). See the API proposal for this.

Global glutDestroyWindow (int windowID)

Clean this up.

Global glutFullScreen (void)

Shouldn't need to XFlush

Global glutHideWindow (void)

Shouldn't need this XFlush

Global glutIconifyWindow (void)

Shouldn't need this XFlush

Global glutInitDisplayString (const char *displayMode)

GLUT_BORDERLESS and GLUT_OFFSCREEN are not represented.

Not all features appear to be implemented. In particular, numeric parameters and comparator specifications are lacking. See GLUT 3.7 sources for example.

PyOpenGL glutInitDisplayString documentation.

Global glutPositionWindow (int x, int y)

Shouldn't need this XFlush()

Global glutReshapeWindow (int width, int height)

Add support for offscreen windows.

Global glutReshapeWindow (int width, int height)

Could delete/create/set-window-id for offscreen.

Global glutSetIconTitle (const char *title)

Shouldn't need this xflush

Global glutSetWindowTitle (const char *title)

Shouldn't need this XFlush

Global glutShowWindow (void)

Shouldn't need this XFlush

Global glutSwapBuffers (void)

How does this interact with overlays?

Consider making GLUT_FPS keep per-window stats in a multi-window program.

Global glutCloseFunc (void(*callback)(void))

There needs to be some work to rationalize the behavior when a window is closed. Presently, the handling is ad-hoc and sloppy.

Global glutDeviceGet (GLenum eWhat)

Keyboards assumed to exist.

Mouse assumed to exist on UNIX/X11.

Mice assumed to have three buttons on UNIX/X11.

Joystick query limited to one joystick

Consider moving to a table-based approach rather than a switch(), letting us move to modular functions.

Global glutGetModifiers (void)

Complains if not invoked by a client callback.

Does not differentiate between the left and right forms of the modifiers.

Global glutTabletButtonFunc (void(*callback)(int button, int state, int x, int y))

We might want to add support for this sooner or later. Although a tablet could also be generalized as a mouse. There are relatively cheap AipTek HyperPen tablets, and slightly less cheap Wacom tablets on many store shelves.

Global glutTabletMotionFunc (void(*callback)(int x, int y))

We might want to add support for this sooner or later. Although a tablet could also be generalized as a mouse. There are relatively cheap AipTek HyperPen tablets, and slightly less cheap Wacom tablets on many store shelves.

Global glutSolidSierpinskiSponge (int num_levels, const GLdouble offset[3], GLdouble scale)

Consider removing the offset parameter from the API (use a helper function).

Global glutSolidTetrahedron (void)

See todo-list on glutWireTetrahedron().

Global glutWireOctahedron (void)

It may be faster (and look better) to draw each edge once, setting the Normal at each edge. (I don't think that this matters all that much, but a lineloop was proposed for the wire Cube for speed.)

Global glutWireTetrahedron (void)

Merge r0 r1 r2 and r3 into one array.

Put the normals into the (or an) array.

Make the array static const, with file scope, and share with glutSolidTetrahedron().

Maybe consolidate with the SierpinskySponge?

Global glutStrokeHeight (void *fontID)

We have discussed adding a "font descender" query. We should go ahead and do it.

Global glutStrokeWidth (void *fontID, int character)

Determine if any glyphs are either wider than this function or if they render outside of the bounding box given by (0,-descent) by (width,height-descent).

Global glutAttachMenu (int button)

Assumes 3 mouse buttons. (Actually OPENGLUT_MAX_MENUS holds the assumed number of buttons.) Cannot bind to more buttons. Will not issue any warnings or errors if the user does not have enough buttons to reach your menu.

Global glutMenuDestroyFunc (void(*callback)(void))

What on Earth is rationale for this feature? Menus should only be destroyed when we ask them to be destroyed, or when their window is destroyed. In the former case, we already know that the menu is being destroyed because we requested it. In the latter case, it is easy for the client to track that if they care, via window-destruction callbacks.

Group gamemode

It behaves differently on different systems. E.g., on some X systems, changing the video mode is impossible. This has led some developers to use game mode as a ``grab the mouse'' mode, without intending a resolution change.

Replacing game mode with a better design was discussed at some length in early 2004.

There is no way for game mode to report a partial failure.

There is no way to guarantee cleanup if OpenGLUT crashes during game mode---or if the client crashes or directly exits, etc.

Some XFree86 releases, with some drivers, can fail to set the video mode properly, resulting in disasterous failure (an unusable display). This is presently somewhat headed off by a compile-time option, but a runtime option would be better, as there may be cases where the user is willing to put up with the risk for some---and only some---OpenGLUT applications. Since game mode applications are somewhat dim-witted about such user preferences, it seems, an OpenGLUT runtime control could be desirable.

Global glutEnterGameMode (void)

Documentation

OpenGLUT may be unable to restore the original settings (this has been observed on WIN32).

Global glutGameModeGet (GLenum pname)

Documentation

OpenGLUT intrepretation of GLUT_GAME_MODE_DISPLAY_CHANGED

Global glutGameModeString (const char *string)

Documentation

Global glutLeaveGameMode (void)

Documentation

Global glutExtensionSupported (const char *extension)

Wouldn't this be simpler and clearer if we used strtok()?

Consider an ogWarning() if there is no current rendering context.

This is an ugly bit of code with 3 return statements, one of which is never reached.

Global glutLayerGet (GLenum eWhat)

Probably we should merge the below sections unless and until layer support is actually added.

Should be set when the window is damaged; should not be set just for glutPostRedisplay().

Global glutSetWindowStayOnTop (GLint enable)

Can a glutGet() be defined to tell us whether a window can be made to stay on top? Or whether a window has (successfully) been marked for staying on top?

Should walk the tree of menus and glutPopWindow() (or all windows that are of menu-window type?).

Investigate making a workalike variant using glutPopWindow() to mimic the feature where not directly supported.

Generated on Sat Feb 5 01:47:28 2005 for OpenGLUT by doxygen 1.3.9.1
The OpenGLUT project is hosted by sourceforge.net.