[gl4java-usergroup] Re: Fulscreen & listener model problems

[Kenneth B. R. <kbr...@al...>]

> The GLCapabilities class of GL4JAVA seems quite different from the base
> capabilities class of JAVA. How do we know what capabilities are used by
> GLCapabilities ? I mean...it's unclear if page flipping is used, or if multi
> bufferring is used for example... are these details hidden from the user, or
> did Sven find out it wasn't worst using them ?

To the best of my knowledge it is not possible to request, for
example, triple buffering in an OpenGL context. It looks like
this is hidden at the driver level. The GLCapabilities abstracts
most of the parameters in the PIXELFORMATDESCRIPTOR on Windows
and the XVisualInfo on X11.


> public class OMWindow extends JFrame implements GLEventListener{
> 
> My program was crashing at runtime, and I finally figured out it was GL4Java
> that was no longer calling the init(GLDrawable drawable) with this class
> configuration depending wich fullscreen resolution I was using. At
> 640x480x60Hz the init() method was called, at 1280x960x85Hz it wasn't...this
> behavior was very weird.

This is unfortunate and very strange but is probably due to some
sort of bad interaction with the AWT native code.


> I decided to split the GLEventListener from the JFrame like it's done in
> jCanyon and put it as a nested class :
> 
> public class OMWindow extends JFrame {
> 	...
> 
> 	class Listener implements GLEventListener {
> 
> 	public void init(GLDrawable drawable){}
> 
> 	...
> 	}
> }
> 
> After the modification, everything went fine...

Personally I don't like subclassing AWT or Swing widgets because
it seems to me there are too many hidden invariants in the
implementations that I don't know how to maintain. Thus the
introduction of the GLEventListener model.


> My second problem was that I was still calling the following methods in my
> display function :
> public void display()
> {
> 	//Ensure GL is initialised correctly
>       if (!glj.gljMakeCurrent())return;
> 
> 	//display code goes here
> 	//...
> 
> 	gl.glFlush();
>       //Swap buffers
>       glj.gljSwap();
> 	glj.gljCheckGL();
>       glj.gljFree();
> }
> The result was that I had my memory use increasing at the speed of 1 meg
> every 10 second, as well as my CPU use wich would increase up to a 100% in a
> minute, resulting in the application slowdown and finally its crash.
> I should have known, since it's written in the FAQ (but has been added by
> Sven in a second pass and I didn't figure it) that when using the listener
> model, these methods are already called by GL4JAVA and you musn't call them
> again. the only method you should keep call is glj.gljCheckGL(); in order to
> track for OpenGL Errors. So with the listener model, the display loop should
> look like this :
> 
> public void display()
> {
> 	//display code goes here
> 	//...
> 
> 	glj.gljCheckGL();
> }

I recall having a similar, but not identical, problem when
porting some applications to the GLEventListener model. Sorry it
wasn't easier to debug this. If you can supply a small test case
which is easy to switch between the "right" and "wrong" behavior
perhaps we can add some code to check for some of these errors.