8 bit color depth support

Why is sub-15 bit color depth support disabled for the Windows platform (see WindowsGLDrawable.java) ? I haven’t tried X11 yet but it looks like it is not disabled there. I didn’t want to just make a feature request to add it because it was specifically disabled. Someone must have had a good reason to do this. I would like to be able to use overlay plane functionality in my video hardware but that is exclusively available in an 8 bit color depth flavor only.

We did this to avoid having to expose a notion of color palettes in the APIs. Setting and fetching color palettes in OpenGL is done with window system-specific APIs which would have meant introducing another abstraction for portability. Since it seemed that 8-bit graphics are on their way out anyway we decided to skip doing this. If you see a strong need even in the current world (what graphics card are you using?) then we can reconsider this for a future release.

The issue with 8 bit support is getting at the overlay plane feature of high-end video cards that have it. I have a mix of nVideo Quadro card and some ATI FireGL cards that have overlay hardware available through OpenGL. I only have Windows installed on these systems. The overlay planes are all associated with 8 bit color depth PFDs. I’m pretty sure that these same cards can be used in Macs, under Linux and also Sun sells them with some of their x64 Solaris workstations.

My assumption, based on limited information, is that overlay planes never really took off as a concept and that it’s possible to emulate their presence by changing how the app performs its rendering. Do you see a strong need for overlay planes in current or potential future applications?

Overlay planes are a very powerful construct. They are commonly used in 3D CAD and GIS. For example if you want to lay a 2D grid over the top of a 3D terrain map. You would draw the grid in the overlay plane and the terrain map in the main plane. You could draw/erase/change the grid without having to disturb the potentially (graphically) expensive terrain rendering. Virtually all fancy-expensive-professional 3D video cards have user level exposed overlay planes. Some even have multiple levels of overlay planes.

You can do the exact same thing with render to texture and have the added bonus that pretty much every videocard made in the last four years supports render-to-texture.

But render to texture an nVidia specific OpenGL extension. Certainly all nVidia cards have this that were made in the last 4 years.

Frame buffer objects can be bound as textures and are available on non-nvidia cards.

It’s still not the same. Overlay planes are a completely separate pool of video memory (different drawing surface) from the main plane. You can scribble all over them and not disturb the contents of the main plane. It’s a common hi-end feature available in the hardware and the native OpenGL that is not available through jogl.

Do you really want to restrict your main rendering to 8 bits of color? Isn’t that going to make it look badly posterized?

Hi, I have seen application using underlay / overlay functionality on Solaris system with very low price/quality cards but as GKW mentionned you can do the same with FBO and I am not sure that performance will be decrease with it… Did you give it a try?

You don’t use overlay planes for ‘main rendering’. You draw relatively simple stuff, like grid lines for a map that come and go or dynamically change, into the overlay planes and your fancy, expensive rendering goes to the high resolution, color rich main plane.

OK, I misunderstood. I thought that you meant that overlay planes were only available for visuals with 8-bit color on your system.

Please feel free to file a bug with the JOGL Issue Tracker about this, but I can’t guarantee that it will be addressed in as prompt a fashion as you would probably like. I would suggest you look into the alternatives that have been suggested here, although I realize that they aren’t really the same thing as a true overlay plane.