color index mode

OpenGL Development JOGL Development
#1

Why does jogl not support the color index mode ?

I want to write an application in a multihead environment, supporting several windows (fullscreen) for each monitor. Each of the GLCanvas displays a different image, and supports a kind of blinking.The blink effect in all windows should be in a synchroneous manner to avoid ergonomic drawbacks.
So the idea is to modify the color index table.

Using the supported RGBA mode, works fine, but “drawing” e.g. 10 images in the back buffer (setAutoSwapBufferMode(false)) and afterwards swapping the buffers of all GLCanvas objects is to slow if the workload is high enough. So a kind delay is visible.

#2

It seemed when desigining JOGL that color index mode was too difficult to expose portably. Additionally it seemed that had been supplanted by true-color mode on most graphics cards.

How many heads do you have on your system? If your aim is to have a full-screen window per head, then you should have one GLCanvas per head and carve up the drawing surface using glViewport and/or glScissor, then swap the buffers once per head.

#3

I use up to 10 heads and one GLCanvas per head.
The blink effect has to be done in a cyclical banner each 0.7s for each of the canvas.
So there are two for-loops one for drawing the new blink state on each canvas and one for swapping buffers a fast as possible :

for (int i = 0; i < ourCanvasList.length; i++) {
ourCanvasList[i].display();
}
for (int i = 0; i < ourCanvasList.length; i++) {
ourCanvasList[i].swapBuffers();
}

But this is not fast enough to avoid visible delay.

#4

What kind of machine and OS are you using for this? Do you have 10 PCI graphics cards shoved into this machine? How many CPUs do you have in this machine?

On SGI systems in the past there were GLX extensions to lock the buffer swap of a graphics card to an externally supplied genlock signal. I have never looked into these extensions in detail but it might be necessary to dive down and use an extension like this.

Also, I don’t think JOGL’s default threading model will work well for your application. By default JOGL serializes all OpenGL work onto one thread which means you’re likely to be performing 20 EventQueue.invokeAndWait() operations in your loop. You should probably specify -Djogl.1thread=false on the command line and fork off a separate thread per head. If you do this you may be able to get away with using Java synchronization (wait()/notifyAll()) or simple volatile variables to synchronize your buffer swapping if not using platform-specific genlock extensions.

#5

At the moment I do a kind of evaluation for a future project. We plan to use WXP and Linux . At the moment i do testing on a P4 with WXP and one Nvidia 400NVS (4 head).
Next week I start testing on XP and Linux on a P4 system with two 400NVS and one 200NVS, so 10 heads are used.
If anybody is interested, I will post a short summary about the results next week.

Concerning your idea, to force JOGL to use more than one thread, (one thread per canvas), I was not successful. Altough I defined -Djogl.1thread=false, I saw in the debugger only one event queue thread for about 4 canvas !?

My idea is to send only one event, a “swapAllBufferEvent” or “swapAllGivenCanvasEvent”. This should be fast enough for 10 heads.

#6

If you specify -Djogl.1thread=false then the OpenGL work inside GLCanvas.display() will be done on the thread on which you call display(). You’ll need to explicitly start say 4 threads, one per head, and call display() in each, waiting for some sort of synchronization from a master thread or similar (ignoring the genlocking extensions for the moment).