[gl4java-usergroup] Fulscreen & listener model problems

[Alban C. <aco...@wa...>]

Hello Kenneth, hi all :)

In reply to a mail of Kenneth, I'm posting a copy of this email to the
mailing list, since I beleive some elements could be interesting for
everyone...

> > (...) I've coded fullscreen mode yesterday and I must say it rocks !! It
has
> > solved my fill rate problem, and my plane model of the little benchmarck
I
> > posted on the mailing list yesterday now runs at 85 FPS at 1280*960*85Hz
> > while it was running at 43 FPS at the same resolution in windowed mode !

> What platform are you running on? Are you using the built-in
> fullscreen support in JDK 1.4? I
> noticed that some fullscreen bits came into the GLCapabilities
> class in Sven's latest putback but it isn't clear to me whether
> it's fully implemented. As long as one specifies
> -Dsun.java2d.noddraw=true on the command line (on Windows), the
> JDK's full-screen support works with gl4java.


The fullscreen mode works on windows 2000 with JDK 1.4 beta 2 gl4Java is
rel-2-8-0-8-prerelease. I haven't had to use any special trick, such as
command line parameter tweaking. Everything went fine, as long as I used
GL4JAVA properly. BUT before succeeding having it working, I met the
problems descibed below in section [PROBLEMS], due to an innapropriate use
of GL4JAVA...

The code I have made is very close of jCanyon's, since it was the only
sample implementation I found, except the ones of the Java Tutorial.
Kenneth, here is the GLCapabilities bit config :
gc = new GLCapabilities(true, false, true, 0, 0, 0, 0, 0);
it's exactly the same as in jcanyon.

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 ?


[PROBLEMS]

While implementing the listener model and fullscreen mode, I've met some
problems :

I had first designed a JFrame class implementing the GLEventListener
interface.
the design was like this :

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.

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...


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 hope this will help some people avoid doing the same mistakes...

Regards,

Alban Cousinie