trouble with display()

OpenGL Development JOGL Development
#1

In my code, i have a section that goes as follows:

...
System.err.print("calling display()...");
pBuffer.display();
System.err.println("...done");
...

in the GLEventListener attached to the pbuffer, i have this:

...
public void display(GLAutoDrawable drawable){
  System.err.print("display() running");
  //do stuff
}
...

most of the time when running, i get (as one would expect):
“calling display()…display() running…done” on stderr.
Every now and then, though, I get a “calling display()…done”; and no output from display().

Is display not supposed to block?

#2

Ken may come and correct me, but I’m pretty sure that I tested that at one point and found that it doesn’t necessarily block. I don’t know if I actually tested it, but I know that in some of my code, I included a flag in the Pbuffer GLEventListener to indicate if the display had actually been performed, and I presume that at the time I thought I had to… Anyway, that sort of makes sense - you’re just shipping out the command to render the Pbuffer to the graphics card, and it can’t necessarily guarantee when its going to get to doing the Pbuffer rendering.

It does seem like that should be noted in the javadocs, though - I looked, and the GLAutoDrawable javadocs don’t specify whether or not display() blocks.

#3

Hmm. You’re right that the GLAutoDrawable documentation doesn’t specify that display() blocks. It really should, as that was the intent. It’s hard to program against it if it doesn’t; for example, calling repaint() instead can swamp the event dispatch thread with repaint requests. I believe there are some circumstances under which a GLJPanel may not block upon a call to display(), but my recollection is that these are rare events and I’d have to refresh my memory by looking at the code. For a GLPbuffer display() should always block. I wonder whether you’re seeing side effects of printing to System.out from multiple threads.

#4

A couple little things that may or may not be significant;

I don’t believe so; note my code uses system.err, rather than system.out, which doesn’t buffer output as badly. The points i was trying to emphasize in the code snippets were that i’m using standard err, and that my output calls are the last thing before the display(), the first thing after it, and the first thing inside it.

Worth noting that it appears to vary significantly according to CPU usage conditions at runtime. Running on a (relatively unburdened… only running our app) production PC, I barely ever observed this, but then running on my dev PC (running lots more stuff), it happens quite a lot.

I’ve implemented a brute force fix (as eteq mentioned) for the time being of clearing a flag and calling display() until it is reset, but hopefully a more elegant fix can come along at some point? Unfortunately I cannot compromise on needing this display() call synchronous.

#5

If you can boil things down into a small test case proving that calls to display() are being executed asynchronously then please file a bug with the JOGL Issue Tracker and attach your test case.

#6

I can try to do that. My issue here isn’t that display() executes asynchronously, but rather that it doesn’t execute at all. I’m never seeing the output from it. When it messes up, it seems to just forget the display() call altogether.

#7

Is this repeatable on different hardware? I looked back at my code, and although I’m still not sure if its blocking, it definitely redisplays the Pbuffer within a fairly short time every time display() is called…