OpenGLUT 0.6.3 development - OpenGLUT: OpenGLUT 1.0 Shaped Window Proposal
Keywords: OpenGLUT, FreeGLUT, OpenGL, GLUT, X11, Windows, Programming, Documentation, Download, Development, Sourceforge

OpenGLUT Documentation
Introduction | Documentation | Examples | Proposals | Authors | Copying | Todo | Bugs | Links

# OpenGLUT 1.0 Shaped Window Proposal

Note:
  This is a proposal for the purpose of discussion and discussion. This API is not currently implemented in OpenGLUT.

This proposal requires some experimenting, and requires learning what can and cannot be done by various systems. It is very tentative.

## Desired: Non-rectangular Windows.

Various applications can benefit from having windows that are of shapes other than simple rectangles. Window-to-window icon dragging is one such area. While this feature is fairly uncommonly used, it is occasionally used to good effect by applications, from media players to clocks to amusements.

## The Proposal.

When a window is created, the client is allowed to bind a the window for defining the window's contour. If there is no callback, OpenGLUT will use a conventional contour.

Sometime after registering this callback, the client will be handed an OpenGL context for a mask associated with the current window. Areas where the client draws white will be opaque; areas where the client draws black will be completely transparent.

## Alpha Blending?

It seems natural to think about alpha blending. In fact, this is an alpha blend with a fixed blending function and (at least) one bit of alpha channel.

This could be done by a full alpha-blend in the window system. However, if the host system only supports an on/off mask (i.e., an alpha depth of 1), a mesh of pixels could be used instead to allow a cheap partial transparency.

## Considerations.

Shaped windows seem of dubious value if the window is not also borderless (GLUT_BORDERLESS or created via glutCreateMenuWindow()).

The implementation may require that OpenGLUT know, when the window is opened, whether it will be a "shaped" window. On such systems, we will be faced with several options:

- Make all windows shaped, with a possible performance penalty.
- Not support shaped windows on that platform.
- Define the API so that one must specify shaping before opening a window with OpenGLUT (i.e., both define a callback and add a displaymode option). Perhaps in that case, the shape callback should be required if you say that your window will be shaped?
- Close and re-open the window when a shape callback is registered, if there was none before. (And possibly close and re-open if the callback is deregistered with a NULL pointer.)

The ``shaped'' term conflicts with the GLUT window-redimensioning operation. It also suggests an on/off boolean state for the pixels. it might be better to think of the shape plane as an alpha channel (which may, regrettably, be rounded to just 1 bit of significance for most window systems today).

This proposal is a place-holder at this time until there is more discussion and some experimentation.

## Feedback

Feedback, comments or suggestions can be directed either to the mail list or discussion forum.
OpenGLUT Development @ Sourceforge
Homepage | Summary | Files | CVS | Forums | Lists | Bugs | RFE
Generated on Tue Oct 5 18:44:33 2004 for OpenGLUT by doxygen 1.3.8
The OpenGLUT project is hosted by sourceforge.net.