Xith 0.71 performance problem?

I switched my RC Flight Simulator (ClearView from http://rcflightsim.com) from older version of Xith to 0.71 (with the new JOGL JSR 371)
The frame rate for a particular scene whent down from 200 fps to 155 fps. Since all other is the same, what is the reason for the big performance hit - the new Jogl or the way Xit3d uses the new Jogl.
The performance hit is acros the board and between 20-25% lower frame rate.

As new versions are released, are you guys checking if there are performance improvements or hits. It would be nice if there is some benchmark that can be used to evaluate the performance of any new version.

Stefan
http://rcflightsim.com

I didn’t have massive scenes so far. So I cannot tell anything about performance losses. But did you notice the release of version 0.8.0 two days ago?

Yes I did. Do you expect 0.8 to be more performant than 0.7 and why ? Ver. 0.7 is the first that implements the new JSR and is based on the new Jogl. I expect 0.8 will perform the same as 0.7. I can try it as well. My question still stands, what made 0.7 slower?

I truely cant say. But give it a try. Never jugde a library without taking a look at the most recent version.

Me, too. But give it a try.

vipbarr, it’s not really surprising that there has been any performance loss from olders to 0.7, because as far as I know c_lilian made a somewhat “naïve” port of the JOGL renderer to JSR-231… Some things may be improved I will look into the code to see if he has left some comments and maybe can he tell himself what can be done to improve performances.

So far no we don’t have any benchmark but if you are ready to provide some data to tests (different polygon-counts, textured or not) I will happily commit them to the toolkit so we can have serious comparisons.

EDIT : And yes the 0.8 shouldn’t come with any performance increase.

The reason I did not try 0.8 is because I need to do massive changes because of TextureLoader API being discontinued (In my view as gratefull user of Xith3d any incompatibility is bad and should not be introduced lightly)
Second, if I changed the code to 0.8 and the prformance was as bad as in 0.7 (and I expect that since the problem is with the JSR 371 port) ) I had to abandon the changes and still use the pre 0.7 version.

To me as game developer (actually my product is flight simulator) improvements are of no value if the prformance suffer. I am not smart enough to know why the code was moved to JSR 371 or why is slow now. I can’t really use it anymore because of the performance hit. I can’t release a new version and tell my users that their rate whent down from 40 fps (that they deemed acceptable) to 30 fps (that they will deem choppy).

If your code is well organized these are not “Massive changes” and we can’t afford keeping a Texture loader relying on com.sun.* classes.
Nevertheless I agree with you that incompatibility shouldn’t be introduced lightly and is bad, but that’s something we sometime have to do :-\

(It’s JSR-231, not 371)

It was moved to JSR-231 because the old JOGL is now officially dead. It is slow now because (IMHO) Xith3D doesnt’ uses FloatBuffers and it is needed to make things like :


Vector4f plane = texGen.getPlaneS();
                         planeBuffer.put(plane.x);
                         planeBuffer.put(plane.y);
                         planeBuffer.put(plane.z);
                         planeBuffer.put(plane.w);
                         planeBuffer.rewind();
                         gl.glTexGenfv(GL.GL_S, glGenMode, planeBuffer);
                         plane = texGen.getPlaneT();
                         planeBuffer.put(plane.x);
                         planeBuffer.put(plane.y);
                         planeBuffer.put(plane.z);
                         planeBuffer.put(plane.w);
                         planeBuffer.rewind();
                         gl.glTexGenfv(GL.GL_T, glGenMode, planeBuffer);
                         plane = texGen.getPlaneR();
                         planeBuffer.put(plane.x);
                         planeBuffer.put(plane.y);
                         planeBuffer.put(plane.z);
                         planeBuffer.put(plane.w);
                         planeBuffer.rewind();
                         gl.glTexGenfv(GL.GL_R, glGenMode, planeBuffer);
                         plane = texGen.getPlaneQ();
                         planeBuffer.put(plane.x);
                         planeBuffer.put(plane.y);
                         planeBuffer.put(plane.z);
                         planeBuffer.put(plane.w);
                         planeBuffer.rewind();
                         gl.glTexGenfv(GL.GL_Q, glGenMode, planeBuffer);

because of that.

Lilian, am I wrong ?

And vipbarr, I see you’re using the Swing GUI : please don’t use it ! It slows down everything incredibly !

Instead, use the new HUD system included in 0.8 (ahem, problem here… but tests it at least…)

I hope I do not offend anybody, you guys do great job and I really hope that in the next versions the porformance hit will be solved. The performance considerations must be top priority if Xith3d is to be used in games. I for myself can’t move to 0.7 or 0.8 because of that.

Please refer to the org.xith3d.test.benchmark package (on CVS), when you create further benchmarks.

I can’t really contribute benchmarks right now, but used this forum to point to the degraded performance after moving to the new Jogl implementation. Can someone tell what is the reason - the new Jogl API is less performant, or the code had to be reworked for the new Jogl API and that made Xith code slower or what else? For those in the midst of this, please shed some light.

Thanks

Well, just as BlueSky told you:

[quote="<MagicSpark.org [ BlueSky ]>,post:5,topic:27774"]
vipbarr, it’s not really surprising that there has been any performance loss from olders to 0.7, because as far as I know c_lilian made a somewhat “naïve” port of the JOGL renderer to JSR-231… Some things may be improved I will look into the code to see if he has left some comments and maybe can he tell himself what can be done to improve performances.

So far no we don’t have any benchmark but if you are ready to provide some data to tests (different polygon-counts, textured or not) I will happily commit them to the toolkit so we can have serious comparisons.

EDIT : And yes the 0.8 shouldn’t come with any performance increase.
[/quote]
So there’s work in progress to fix the performance leak.

[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:27774"]
And vipbarr, I see you’re using the Swing GUI : please don’t use it ! It slows down everything incredibly !

Instead, use the new HUD system included in 0.8 (ahem, problem here… but tests it at least…)
[/quote]
vipbarr, did you notice that ?

Well… I haven’t deeply benchmarked my port of xith to jsr231… could you try and run the “cube test” (thousand cubes moved on screen, in the test package) and see how it compares with the old jogl implementation ?

I’m planning on a second pass on the renderer next month to optimize things a la java3d (use small display lists everywhere possible instead of direct ogl calls). That should boost the perfs on some cases where there are many different objects / states.

In the meantime, I’m rather busy and cannot contribute or help right now…

Regards,

Lilian :slight_smile:

OK.

[quote="<MagicSpark.org [ BlueSky ]>,post:13,topic:27774"]

[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:27774"]
And vipbarr, I see you’re using the Swing GUI : please don’t use it ! It slows down everything incredibly !

Instead, use the new HUD system included in 0.8 (ahem, problem here… but tests it at least…)
[/quote]
vipbarr, did you notice that ?
[/quote]
Yes I did. I am not using it now. I used it before for FPS counter only and saw no noticable perf. degradation.