intel 82852/82855 GM/GME problems

I have a problem with the intel 82852/82855 GM/GME and my Jogl application. With Jogl 1.1.1, it works fine, but with beta 2 it seems to have a double buffer problem. I’m using a GlCanvas and the FPSAnimator (custom but very similar code for the 1.1.1 version).

It seems to constantly alternate between the previous frame and the current frame, causing a jittering effect.

Jogl 1.1.1 version: http://spdc.sdsc.edu/iedb/protein_workshop/jogl_test2.php
beta 2 version: http://spdc.sdsc.edu/iedb/protein_workshop/jogl_test4.php

Does the Gears demo work properly on your machine?

Are you calling swapBuffers() manually anywhere? It looks like you shouldn’t be nor need to.

Are you doing any manual OpenGL context manipulation using the new JSR-231 APIs?

Both look fine on my machine (NVidia mobile hardware). One tip though is that it looks like you don’t need to use an Animator at all since your geometry isn’t animated and since it looks like the app is event-driven. Eliminating the use of the Animator should cut down your CPU usage significantly and may also eliminate any problems you’re seeing.

Yeah, it works fine for the majority of other video cards. The gears demo on the jogl-demos site works fine. No, I’m not calling swapBuffers() in my code.

What do you mean by context manipulation? I’m probably not.

Yeah, you’re right about the animator. I’ll remove it.

Are you requesting a custom GLCapabilities or just using the defaults? If you’re specifying anything special, could you just use the defaults and see if that changes the behavior?

I’m basically asking whether you used any of the new JSR-231 APIs like GLContext directly when bringing your application forward from JOGL 1.1.1 to JSR-231 beta 2.

I’m using the default GLCapabilities, and I’m not using GLContext.

My initialization code for the GLCanvas is below. In the display() and init() functions, I just get the GL from the GLAutoDrawable and start using it.


glCanvas = new GLCanvas(glCapabilities);/GLDrawableFactory.getFactory()
.createExternalGLDrawable().createGLCanvas(glCapabilities);
/
glCanvas.addGLEventListener(this);

	add(glCanvas);
	glCanvas.setFocusable(false);

	// Start rendering
	animator = new FPSAnimator(glCanvas, 100);
	animator.start()

What OpenGL functionality are you using to draw your geometry? Vertex arrays? Vertex Buffer Objects?

Have you tried plugging in the DebugGL pipeline in your init() routine? Are there any reported errors?

Someone here at Sun indicated that on some Intel hardware he was seeing that no double-buffered pixel formats were available, which is hard to believe but possibly true. Still I don’t know why the Gears demo would behave properly while your app wouldn’t.

Actually, yeah, there’s a difference in geometry storage between the two versions. In the Jogl 1.1.1 version, I’m using display lists for almost everything. In the beta 2 one, after trying array lists (http://spdc.sdsc.edu/iedb/protein_workshop/jogl_test3.php), I found there was too little video card support for them. So I moved back to display lists, but only used them for the array list data - vertices and normals - to retain the flexibility. All matrix operations and coloring is done in immediate mode in the beta 2 version.

Yeah, I’m using the DebugGL pipeline. It doesn’t report any errors.

I’ll get the pixel formats from the Intel card tomorrow, for kicks. Any other debug info that might be useful?

Could you maybe also post the output when -Djogl.debug.WindowsGLDrawable is specified when running on the Intel chipset? At least for beta 2 – I think it will also produce output for 1.1.1.