hardware acceleration breaks with new version

Hi,

Great work!
I’ve been using JOGL 1.0 for a long time now, and it has worked perfectly.

I do have a problem however. Since the newer JOGL version is out, I immediately got it. The first thing I noticed when I ran my code was my textures were no loaded anymore. I use large textures (2048x1024). I changed the textures to small ones, and now it worked.
Still my framerate has dropped from aboiut 100 to 5, and my screen flickers all the time.

I think this could be due to the lack of hardware accelleration -> no double buffering, slow drawing.
I will switch back to the old version, i guess. Anyone got any ideas about this?

I use a 2Ghz AMD, with INTEL graphics accelerator. (I know that is not much of a graphics card, but the old JOGL worked perfectly fine on this card).

any help is greatly appreciated…

I just noticed that with the new version of JOGL, it uses the windows GDI renderer, and the old version used the Intel … renderer. So now I know for sure I have no hardware accelaration as Microsofts implementation sucks. The GEARS demo also flickers and run slow because it uses the wrong renderer. Why does the new JOGL version not support the intel graphics accelerator anymore?

My system is a Dell optiplex, and I am running Windows XP.

Am I missing something here, or is this a bug that was introduced with the new version?

Please help

I noticed this as well. I had to write my own capabilitieschooser to make it not pick a non-accelerated mode.

How did you do that?

I have teh problem of slow drawing anyway…

I’m glad I’m not the only one having this problem.

Markus, could you possibly post some code that fixed the problem for you?

I do create my own GLCapabilities object, and set the hardwareAccelarated flag to true. This doesn’t help me at all…

For a test I took the code from DefaultGLCapabilitiesChooser.java and implemented my own Chooser.

My Canvas is the created with:

GLCanvas canvas = GLDrawableFactory.getFactory().createGLCanvas(caps, new CapsChooser());

Caps Chosser is my CapabilitiesChooser with the code from DefaultGLCapabilitiesChooser.java.

The new DefaultGLCapabilitiesChooser has code for a windowSystemRecommendedChoice, seem’s to me that it uses the prefered mode from the OS (If there is any) and this choice has no Hardware Acceleration on my system, so I removed the new stuff and all runs fast…

I did what ank53 said, except I wrote my chooser from scratch. (I’m a control freak. ;D)

It iterates over all available capabilities, and picks the “best” one. A capability without hw acceleration rates very very low indeed.

The nice thing about running your own code is that you can do fancy things like prioritize different capabilities. So an alpha color channel might be more important than a stencil buffer for example.

[quote]I did what ank53 said, except I wrote my chooser from scratch. (I’m a control freak. ;D)

It iterates over all available capabilities, and picks the “best” one. A capability without hw acceleration rates very very low indeed.

The nice thing about running your own code is that you can do fancy things like prioritize different capabilities. So an alpha color channel might be more important than a stencil buffer for example.
[/quote]
Would you be willing to contribute this? Do you have confidence that it behaves better than the DefaultGLCapabilitiesChooser (which admittedly is a hack, but one which has seemed to work well until recently)? If yes, would you submit a patch on the JOGL issues page?

Well, sure.

I wouldn’t guarantee that it’s better than the default one, but since mine at least picks an accelerated mode (hint, nudge), I prefer it. :wink:

I’ll clean it up and post it tonight.

Thanx all for your replies. I havent tried it yet, but now at least I got an idea where to look. I think Ill wait untill Markus posts his patch. :stuck_out_tongue:

Keep up the good work! :wink:

Sorry about the delay… here’s the latest version of it:

http://www.mojang.com/ScoreCapabilitiesChooser.java

And here’s now I use it in the current Wurm client:

ScoreCapabilitiesChooser scoreCapsChooser = new ScoreCapabilitiesChooser();

scoreCapsChooser.requiredHardwareAccelerated = true;
scoreCapsChooser.alphaBitsScore = 20;
scoreCapsChooser.verbose = true;

canvas = GLDrawableFactory.getFactory().createGLCanvas(glCaps, scoreCapsChooser);

You can set the minimum required level per property, and the score for each “unit” of each property. So you can make each bit of stencilbuffer twice as valuable as a bit of alpha buffer.

It works by sorting all capabilities according to their scores, then looking up the index of the best scoring capability in the original array.
It currently doesn’t throw any exceptions if it fails to find an acceptable capability, but that should be trivial to add.

(in fact, it’s as simple as if (getScore((GLCapabilities)sortedCaps.get(0))<0) throw new IllegalArgumentException(“No compatible capabilities found”):wink:

Thanks. I’ve filed Issue 81 to track this.