Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (580)
games submitted by our members
Games in WIP (499)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  jogl vs. lwjgl speed test  (Read 13017 times)
0 Members and 1 Guest are viewing this topic.
Offline DavidYazel

Junior Member




Java games rock!


« Posted 2003-07-14 00:57:44 »

I ran some speed comparisons against both API's.  The tests were of cubes being rotated an dtranslated around the screen.  Each cube has 16 triangles. Each cube is being rendered via vertex arrays in both api's.  

100 cubes:
lwjgl : 543 fps
jogl: 428 fps

300 cubes:
lwjgl: 237
jogl: 214

500 cubes:
lwjgl: 159 fps
jogl 150 fps

900 cubes:
lwjgl: 96 fps
jogl: 90 fps


I am gratified to see similar performance.  In the last test both were pushing close to 1 million triangles/sec.



David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #1 - Posted 2003-07-14 01:10:30 »

Nice, thanks.  Cheesy
Those numbers look pretty good.


Could you post the source code for the rendering loop from either and/or both?

Play Minecraft!
Offline DavidYazel

Junior Member




Java games rock!


« Reply #2 - Posted 2003-07-14 01:37:06 »

Well its a little hard to post a snippet since this is running in our Xith3d renderer off of a Java3d scenegraph.  The renderer is sitting at 12,000 lines of code as of tonight. (wow, I have been busy the last 2 weeks).

But basically the test scene is just two nested transform groups, one for rotation and one for translation.  So a mass of cubes are randomly placed around the origin and then the mass is rotated and translated on each frame

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
        Random ran = new Random(35354);
        for (int i=0;i<900;i++)
        {
            Shape3D shape = new Shape3D();
            Appearance a = new Appearance();
            a.setPolygonAttributes(new PolygonAttributes(PolygonAttributes.POLYGON_FILL,PolygonAttributes.CULL_BACK,0));
            Geometry g = createCube(1-2*ran.nextFloat(), 1-2*ran.nextFloat(), 1-2*ran.nextFloat(), .5f, true);

//            Geometry g = createCube(0.5f-ran.nextFloat(),0.5f-ran.nextFloat(),ran.nextFloat()-0.5f,0.5f,true);
           shape.setAppearance(a);
            shape.setGeometry(g);
            tf_2.addChild(shape);
            ShapeAtom atom = new ShapeAtom(shape);
            r.addAtom(atom);
        }


nothing special about the cubes.  I am not lighting them, just rendering them with vertex colors.  Since the engine sorts states and transforms and only switches the openGL states on changes we basically will have the following rendering pipeline:

1. setup view
2. set model transform
3. set polygon attributes
4. set rendering attributes
5. setup vertex array and draw

repeat step 5 for each shape, which is 900 in the last test case.

I am going to add an enhancement that detects duplicate geometry and sorts dup geometry seperatly, so we should be able to use the same vertex array over and over.. should be faster.

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #3 - Posted 2003-07-14 03:02:51 »

Here is what I'll comment on JOGL vs LWJGL. The more time you spend rendering (i.e. a real game) the less performance difference you'll see between the two. JOGL and LWJGL are doing the native bits the most optimal way and the rest is all philosophy of API design. There is a bit more native code in LWJGL, but once things really get going - much of the benefit of some of its native bits starts getting lost in the shuffle just as Amdahl's Law dictates.

Quote

Amdahl's law states that the performance improvement to be gained from using some faster mode of execution is limited by the fraction of the time the faster mode can be used.    

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline cfmdobbie

Senior Member




Who, me?


« Reply #4 - Posted 2003-07-14 03:04:15 »

Good to see that's pretty much what I'd expect! Grin  LWJGL is a little faster due to its use of raw int pointers, but the difference isn't really much.

Now, will the numbers change with LWJGL 0.7? Roll Eyes

Hellomynameis Charlie Dobbie.
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #5 - Posted 2003-07-14 06:13:05 »

Quote
Now, will the numbers change with LWJGL 0.7?
Well, theoretically it should be more equal, however - since our native code is much leaner, I would still expect LWJGL to be faster...

Offline cfmdobbie

Senior Member




Who, me?


« Reply #6 - Posted 2003-07-14 16:55:24 »

Any wager on that? Grin

Ah, much as people bemoan the redundant parallel effort, I do so love seeing competition!

Hellomynameis Charlie Dobbie.
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #7 - Posted 2003-07-14 19:40:17 »

Tell you what, if LWJGL is NOT faster than any other general purpose binding, then I will make damn sure it is! - at least on the win32 platform... I am pretty sure that elias has the same feeling.

Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #8 - Posted 2003-07-14 19:54:09 »

Speed's not everything, you know. Wink

The main reason I'm switching to Jogl from LWJGL is partly to get rid of the weird native windows, and partly because it's more "official".

The opengl part of the rendering loop is rarely the bottleneck, so having 10-15% faster opengl calls doesn't really matter that much in a real app.
But it does make for pretty benchmarks. Wink

Play Minecraft!
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #9 - Posted 2003-07-14 20:36:56 »

For any non trivial application I would actually be surprised to find a measurable difference in speed since most of the game (its controller paradigm, AI, gameplay... the game parts) are going to happen in common Java code.

With the actual bindings both using native byte buffers to pass large byte arrays to the actual opengl calls, the biggest bottleneck in an OpenGL binding is already out of the way. Having done a profile on a couple of my applications - outside of calling the actual OpenGL functions, my application spends most of its time in good old Java methods.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #10 - Posted 2003-07-14 20:55:49 »

Quote
But it does make for pretty benchmarks.

But since we can't compete on being more official, there is only API & speed left...

API wise, I think we win hands down - *much* simpler to use the LWJGL api, than using jogl et al. (bar documentation Tongue).

So if we can be a bit faster and have a "better" API then I think we succeded - now we only have to get the other platforms (ie. Mac OS X) along too...

Quote
get rid of the weird native windows

Whats wrong with the window? - if we don't know what the users dislike, we cannot fix it...

Offline DavidYazel

Junior Member




Java games rock!


« Reply #11 - Posted 2003-07-14 21:12:05 »

Heh and it bugged me that you cannot *get* the wierd native window in JOGL.

How many commercial games "fake" full screen by placing a window over the screen?  UH.. probably none.

Not to mention changing the display modes based on the user settings, not on the current display.

I like to play games at 1200 pixels wide, but I can't stand editing at that resolution.  Many people feel the same way.

I am glad to see that JOGL can actually draw the screen that quickly within an AWT window, I had worried that there migiht be some wierd buffering which would cost performance.

Basically with Buffer support for textures and geometry JOGL will always be in the running for shear speed.

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #12 - Posted 2003-07-14 21:12:33 »

Well, you can't set the icon on the window, you can't use it for anything other than OpenGL (like make it only use half the height for OpenGL and the other half for Swing), you can't resize it, you can't move it, and it insulted my sister.

Other than that, I guess it's fine.  Wink

[size=1][Edit: I accidently invented "OpenLG"][/size]

Play Minecraft!
Offline Matzon

JGO Knight


Medals: 19
Projects: 2


I'm gonna wring your pants!


« Reply #13 - Posted 2003-07-14 21:50:17 »

Quote
Well, you can't set the icon on the window, you can't use it for anything other than OpenGL (like make it only use half the height for OpenGL and the other half for Swing), you can't resize it, you can't move it, and it insulted my sister.


Setting the Icon: think we will implement this RSN, since others mentioned that too.

Yes, it is a OGL window only - if you need to mix and match with ordinary java components, you need to use jogl or gl4java - this is just a fact, since we'd prefer to not use any AWT stuff at all.

Resizing isn't possible, since it introduces a gazillion errors - and basically, most games don't need it!!

Moving window should be possible... works fine here - old release you tried last?

Insulted your sister??? - J/K?

LWJGL is for *gaming* - if you need a general purpose library, by all means use jogl or gl4java - but if you want a no frills simple api for getting a game running (windowed or fullscreen) using ogl, then LWJGL is your best bet!

Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #14 - Posted 2003-07-14 21:56:47 »

I mean there's no way of moving the window from within the code. Sure, that's not exactly something you'd want to do. Wink

The sister thing was a joke, yes.


But I agree about LWJGL being better than Jogl api-wise.
I really hope the Jogl people (ahem, nudge-nudge Wink) change their minds and open up the API a lot more. Having the only buffer swap being called when the only thread that can perform any GL commands returns is just.. strange.

Play Minecraft!
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #15 - Posted 2003-07-14 22:33:40 »

Quote
But I agree about LWJGL being better than Jogl api-wise.
I really hope the Jogl people (ahem, nudge-nudge Wink) change their minds and open up the API a lot more. Having the only buffer swap being called when the only thread that can perform any GL commands returns is just.. strange.


Just curious 'cause I haven't done much of anything with OpenGL yet... Do you typically have a need to swap buffers in more than one place in your render loop?  When this "feature" of JOGL was described earlier I thought it made sense, even if it might be "weird" if you expected to be swapping the buffers manually.

Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #16 - Posted 2003-07-14 23:16:11 »

Not in the rendering loop, no. But you can't for example have a method like this in Jogl:

1  
2  
3  
4  
5  
6  
7  
8  
9  
public void init()
{
   for (int i=0; i<texturesToLoad(); i++)
   {
      loadTexture(i);
      renderProgressBar();
      swapBuffers();
   }
}

Play Minecraft!
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #17 - Posted 2003-07-15 02:08:01 »

LWJGL is most assuredly good Gaming API goodness - no one will ever be able to take that away, but there are somethings about the way it wants to do things that are annoying as well - such as Wurmonline trying to draw at the fastest refresh of the videocard when my LCD monitor cannot render at that refresh Smiley Would have been nice if there was an external configuration application for LWJGL so I could say *don't do this*...

Both of the APIs are going to have growing pains, but within a year I expect that people will be creating real games with both without issue.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline aNt

Senior Member




AFK


« Reply #18 - Posted 2003-07-15 07:01:37 »

yep! more of a 'jogl and lwjgl' then a 'vs' Smiley.
Offline vydias

Senior Newbie




Welcome to my world!


« Reply #19 - Posted 2003-07-16 05:13:50 »

Quote
Not in the rendering loop, no. But you can't for example have a method like this in Jogl:

1  
2  
3  
4  
5  
6  
7  
8  
9  
public void init()
{
   for (int i=0; i<texturesToLoad(); i++)
   {
      loadTexture(i);
      renderProgressBar();
      swapBuffers();
   }
}


That is why with jogl you would use another thread for resource loading and thus have the same effect as others have stated as a good idea.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public void init(GLDrawable drawable) 
{
    loadTextures = new TextureLoader();
    loadTextures.start();
    .....
}
public void display(GLDrawable drawable)
{
    if(loadTextures.LOADING)
    renderProgressbar(drawable);
    ........
}

Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #20 - Posted 2003-07-16 14:16:52 »

That won't work. The other thread can't perform any OpenGL commands.

Play Minecraft!
Offline vydias

Senior Newbie




Welcome to my world!


« Reply #21 - Posted 2003-07-16 14:31:29 »

um, ok your right pass in GLDrawable to the threaded loader and there you go.
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #22 - Posted 2003-07-16 14:54:49 »

I fail to see how that would help..

Play Minecraft!
Offline tortoise

Junior Member




<3 Shmups


« Reply #23 - Posted 2003-07-16 15:10:52 »

Is it possible to have more than one GLUpdateListener going at the same time? If so, wouldn't that solve the problem?
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #24 - Posted 2003-07-16 16:09:36 »

Nope, the DrawableHelper will call display on all the listeners before returning to invokeGL in the GLContext, where the swapBuffers() is performed.

(in other words, display() on all the listeners must return before the buffers are swapped)

Play Minecraft!
Offline vydias

Senior Newbie




Welcome to my world!


« Reply #25 - Posted 2003-07-16 18:09:11 »

Maybe I'm missing something here but in the Threaded example I only need access to the GLDrawable to load in the textures.

If this is threaded why can I load textures in a seperate thread and set an animator to start the openGl rendering and only break into my progressbar rendering as textures are being loaded?
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #26 - Posted 2003-07-16 18:21:04 »

glDrawable.getGL()?

Does that work on both linux and windows for you?

Play Minecraft!
Offline vydias

Senior Newbie




Welcome to my world!


« Reply #27 - Posted 2003-07-16 20:31:10 »

I only develop for windows initially so I don't know about linux.  After I have a windows version any code that needs porting i.e. our exe (autoudates, checks jvm version sets paths ecodes all java files, etc..) and our actually game code will be ported at that time.

So if this doesn't work under linux that is good to know but it isn't a very big concern for those working with this under windows which IMO is probably the vast majority of developers.
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #28 - Posted 2003-07-17 00:10:29 »

And if it doesn't work, that's a bug that should be dealt with and not something that you should be trying to code around.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Markus_Persson

JGO Wizard


Medals: 12
Projects: 19


Mojang Specifications


« Reply #29 - Posted 2003-07-17 00:18:19 »

Then what's all this I keep hearing about the only legal place to perform opengl calls is in the invokeGL method in GLContext?  Huh

Play Minecraft!
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (44 views)
2014-04-15 18:08:23

BurntPizza (40 views)
2014-04-15 03:46:01

UprightPath (56 views)
2014-04-14 17:39:50

UprightPath (38 views)
2014-04-14 17:35:47

Porlus (54 views)
2014-04-14 15:48:38

tom_mai78101 (77 views)
2014-04-10 04:04:31

BurntPizza (136 views)
2014-04-08 23:06:04

tom_mai78101 (236 views)
2014-04-05 13:34:39

trollwarrior1 (197 views)
2014-04-04 12:06:45

CJLetsGame (205 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!