swap buffers (Windows, multi-threaded)

OpenGL Development JOGL Development
#1

Hi. I just found out about nightly builds, and decided to try the Windows one to see if it differs from the September binary I’ve been using. (I still haven’t been able to build with win32.vc6 or win32.vc7.)

With the September binary, I have some issues with threading to work out. We’ve got a complex system that puts OpenGL rendering into a separate thread. In the GLEventListener.display() method that comes from AWT, I tell the thread to do some rendering and return. In the rendering thread, I do a setNoAutoRedrawMode(false) and setRenderingThread(Thread.currentThread), then call GLCanvas.display(). I’ve got a callback interface that I use to go to my rendering, rather than telling the renderer thread to go again. Every now and then, I have a hang, because of synchronized methods inside GLContext.

I can mostly get around them by not allowing auto redraws until I’ve made a picture for the last one (one pass through display() as AWT, followed by one as my rendering thread). I’m afraid I’ll lose an update at some point, and there are further complications which might still lead to a hang.

So I was hoping that the more recent build would have something to help. I can’t point to a Jogl problem, however–it seems it is an effect of the design.

Anway, I get one picture, but when I try to make more, I get a GLException complaining of an error swapping buffers.

Can I get more info about that error? I see a glGetError(), but I’m looking for a Windows (wgl, specifically, I think) error, rather than an OpenGL error.

I’m interested in help on the threading stuff, or what might be the difference between the September build and the current nightly, or on how to find out why the swap buffer failed.

I haven’t really looked at the demos, assuming they are there to show off OpenGL abilities, rather than architectures using Jogl. If one of those is intended to show a more complex interaction with rendering threads, etc, please suggest it to me. (I guess it is time to take a look, anyway…)

thanks
andy

#2

Right after you ask a big question, you always find out something else. :slight_smile:

I have been switching a lot of things around, and the swap buffers issue seems to be what you get when you don’t use DebugGL to find there is a problem before you get to swap buffers. So I put that back, and I’m getting something else. It is a java.lang.OutOfMemoryError. That’s what I seem to get when I have problem with my rendering threads, etc. So I’ve got some debugging to do. But I still wouldn’t mind talking with someone who is using the rendering thread stuff at a complex level.

thanks
andy

#3

So I pointed my IDE to a source directory, even though I didn’t build it myself, and started following Jogl through the generated code.

In DebugGL, when I call glClearDepth(), I get to a loop in checkGLGetError(). This loop is supposed to get all the accumulated OpenGL errors. As far as I can tell, it is looping so many times (reporting invalid operation), that it eventually fills up the string buffer it is using for a message, and has an out of memory error.

Have I really put that many invalid operation errors on the thing, or is there a problem with this code?

thanks
andy

#4

glGetError automatically clears the error flag that you’ve just received info about, and I’m willing to bet that theres only a small(ish) amount of different error flags. Even if you were doing something horribly wrong I wouldn’t expect any more than 16 errors in one go, which shouldn’t really trip an out of memory error.

Could this be bad drivers not clearing the error after its returned? What graphics card & drivers?

Have you tested any other OpenGL apps (both LWJGL and native ones)?

#5

w/o looking at any source or knowing anything about JOGL particularly, I have two observations:

  1. OpenGL errors are not cumulative - a new error should be overwriting a previous error; and

  2. Calling glGetError() inside a glBegin()/glEnd() is itself actually an error. Caught me out unexpectedly a couple of years ago and it’s very difficult to spot!

Cas :slight_smile:

#6

I’m switching between TraceGL and DebugGL, since I get different things. DebugGL checks glGetError() more often, but crashes as it keeps appending to the same string–glGetError() doesn’t seem to be clearing the error. TraceGL doesn’t hit that error, but there’s an effect later, as it tries to swap buffers at the end. It does let me look for whether I’ve got too many begins for the same number of ends, though–and I don’t see any.

The checkGLGetError() method in DebugGL does have a check for whether it is called in between a glBegin and glEnd, and it doesn’t think it has been.

So now I’m calling glGetError() at the beginning and end of each pass through my GLEventListener.display() method. Before and after the AWT thread calls it, I get no error. Before and after my rendering thread calls it, I get 1282 (which is 0x502, which is invalid operation).

So my three questions now are:

  1. What caused that error after the last call to display (either by my rendering thread or AWT, where the last OpenGL call was to glGetError(), returning 0)? If we were after a glBegin() and before a glEnd(), I could see getting continual errors when calling glGetError(). But the last OpenGL command that TraceGL tells me about (though on another thread) is glGetError(), with no error.

  2. What changed between the September build and the current one?

  3. If the glGetError() is not being called between glBegin() and glEnd(), how come it isn’t clearing the error?

Any chance I’m mixing one jogl.jar file with the wrong jogl.dll file? Are there version checks between the two? I did search for other files, but didn’t find anything in a path that I thought I’d pick up accidentally.

I tried turning off hardware acceleration, and got the same behavior in the trace. However, the colors in my picture were all wrong. That surprises me, as I’m used to being able to turn off hardware acceleration and get a pretty stable OpenGL.

I’m running Windows 2000, with a GeForce4, driver version 6.14.10.5216.

andy

#7

I know I’m responding to myself a lot, but if I raise the questions ???, I like to give some answers. :slight_smile:

Turning off hardware acceleration messed up the colors because we typically assume accumulation buffers. There were some available, but the default GLCapabilities assumes 0, so the capabilities with 16 accum bits were over-qualified. I set the accum bits in the capabilties, and that works.

But I’m not any closer on the glGetError() thing or my original threading issues. Time to make a separate testapp to show what I mean.

andy