Why is AWTGLCanvas so much faster than the native Display?

[Qudus]

The title says it. In Xith3D using the native Display class to handle the OpenGL context is comparably fast to JOGL. But using AWTGLCanvas is much faster! Why is this? Am I doing anything wrong?

Here is the context handing class for the Display class: http://xith3d.svn.sourceforge.net/viewvc/xith3d/trunk/src/org/xith3d/render/lwjgl/CanvasPeerImplNative.java?view=markup
And here is the one for the AWTGLCanvas: http://xith3d.svn.sourceforge.net/viewvc/xith3d/trunk/src/org/xith3d/render/lwjgl/CanvasPeerImplAWT.java?view=markup

As you can see, the only really differing code is the constructor, where the display is created and of course the extended AWTGLCanvas. These two classes are the only ones, that differ for these two renderers.

In the Quake3 flight test I get about 200 FPS with native LWJGL and 275 FPS with the AWTGLCanvas, which is a quite amazing number. And I would like to get this number for native LWJGL, too, if possible.

Any thoughts? Thanks.

Marvin

PS: In both cases I use an 800x600x24 sized non-fullscreen window and no vsync.

[darkprophet]

Im sorry, but if you expect people to help you, provide a self contained test case. Uploading a very Xith-3D centred class isn't going to help much since a) I can't run it. b) I dont know how/when/why you call those methods and under what circumstances.

Self contained test case please

DP

[Qudus]

Well, the constructor is called with the parameters explained above (+ null owner, 24 bit depth buffer).
The makeCurrent() method is called when the Thread to be used for rendering is not the current context-thread (which is never in my case).
The initRenderingImpl() method is called each thread to invoke the rendering.

That's all.

Of course a self contained testcase would be best, but I have no experience with using LWJGL directly. So creating a testcase, that actually renders something, is very hard for me. I thought, the class was that short (considering only the three used methods), that it might help you do tell me, if I'm doing something obviously evil.

If the code plus these explanations is not enough, I would suggest, that I simply create a testcase, where the display is created like in my classes and you can insert your rendering code at the right place. I'm sure, you have some amazing render examples in your repertoire . Would that be sufficient?

Marvin

[Matthias]

Well - switching context is very slow anyway - so stop doing it and you get a much higher framerate. Also don't call glGetXYZ() - it works against multi threaded OpenGL drivers (like the nVidia one).

Ciao Matthias

[Qudus]

Thanks for the quick reply.

Well - switching context is very slow anyway - so stop doing it and you get a much higher framerate. Also don't call glGetXYZ() - it works against multi threaded OpenGL drivers (like the nVidia one).

This might be a dumb question. But where am I switching the context? If you're talking about the makeCurrent() call, then remember, that I said, that this method is never called in my testcase.

I only call glGetXYZ in the initialization phase, this should be ok, isn't it?.

Marvin

[Qudus]

Is there an example for the usage of AWTGLCanvas somewhere?

[bobjob]

is it possible that the vsync isnt working in the awt version?

[Qudus]

is it possible that the vsync isnt working in the awt version?

I am not using vsync in both cases.

[wolf_m]

If the code plus these explanations is not enough, I would suggest, that I simply create a testcase, where the display is created like in my classes and you can insert your rendering code at the right place. I'm sure, you have some amazing render examples in your repertoire . Would that be sufficient?

Marvin

See http://lwjgl.org/wiki/doku.php/lwjgl/tutorials/opengl/basicopengl#rendering_our_square (method: render()) for very simple, thus high-framerates GL code. This should introduce an even bigger gap if the native Display is actually the problem here because if there's a slowdown per frame, this slowdown results in a higher difference with more frames per second, obviously. If the difference in FPS remains the same, there's some subtle difference on xith's side or the problem is this ominous Q3 flight thing. Or something entirely different.
You need to increase angle every gametick to let the cube rotate, by the way.

Why don't you ask the xith guys as well, by the way? They should know what the problem is. http://www.xith.org/forum/index.php

[Qudus]

See http://lwjgl.org/wiki/doku.php/lwjgl/tutorials/opengl/basicopengl#rendering_our_square (method: render()) for very simple, thus high-framerates GL code. This should introduce an even bigger gap if the native Display is actually the problem here because if there's a slowdown per frame, this slowdown results in a higher difference with more frames per second, obviously. If the difference in FPS remains the same, there's some subtle difference on xith's side or the problem is this ominous Q3 flight thing. Or something entirely different.
You need to increase angle every gametick to let the cube rotate, by the way.

Cool. Thanks. I will create a testcase now...

Why don't you ask the xith guys as well, by the way? They should know what the problem is. http://www.xith.org/forum/index.php

Haha . Yes, maybe I should ask... myself .

Marvin

[Qudus]

Here is a testcase. Unfortunately I didn't get the AWT version to render. Don't know, why. Please have a look at it. Thanks.

Btw. In the wiki is an article about LWJGL and AWT, but it isn't written yet. It this planned?

Marvin

EDIT: Modified the testcase to avoid AWT threading issues. But it didn't make it render, too.

[Qudus]

Any news here? Is the testcase good? Or do you need some more explanations?

This is very important. Would be extremely cool, if someone could have a look at it. Thanks.

Marvin

[Matzon]

not sure about your test case  - seems needlessly complex 

check org.lwjgl.test.opengl.awt.AWTGears and org.lwjgl.test.opengl.Gears

Same application - one using native display - the other awt

[Qudus]

Thanks.

Running these two tests I get the following results:
Gears:
13013 frames in 5.0 seconds = 2602.6
14154 frames in 5.0 seconds = 2830.8
14290 frames in 5.0 seconds = 2858.0
17005 frames in 5.0 seconds = 3401.0
14312 frames in 5.0 seconds = 2862.4
14356 frames in 5.0 seconds = 2871.2
14347 frames in 5.0 seconds = 2869.4
14346 frames in 5.0 seconds = 2869.2

AWTGears:
14955 frames in 5.0 seconds = 2991.0
20794 frames in 5.0 seconds = 4158.8
18682 frames in 5.0 seconds = 3736.4
18501 frames in 5.0 seconds = 3700.2
18504 frames in 5.0 seconds = 3700.8
22683 frames in 5.0 seconds = 4536.6
23671 frames in 5.0 seconds = 4734.2
22475 frames in 5.0 seconds = 4495.0
21372 frames in 5.0 seconds = 4274.4

So the AWT version appears to be a lot faster. Do you get similar results? Why is it (that much) faster? I would expect the "direct" LWJGL way to be the most efficient way, wince there's no AWT overhead to deal with.

Marvin

[Matzon]

I get twice the performance using the Native display compared to AWT.
What graphics card?
Do you have some weird forced settings in your driver panel ?