What that really shows you is just how good Jet is 
What about the 1.6 server VM? In days gone by I generally found the server VM to be about 30% faster than the client VM, matching Jet typically (except of course on startup time which Jet rules).
Cas 
athlon 64 x2 4200+
3gb ram
1.6 client vm
29 fps / 88% cpu with version 8
32 fps / 99% cpu with version 10
2.16 Ghz Core 2 Duo, Java 5 on Leopard (Activity Monitor reports 200% CPU if both cores are fully utilized)
33 fps, 160% CPU with version 8
33 or 36 fps, 175% CPU with version 10
Version 8 was consistent - always around 33fps.
Version 10 varied on each execution. One execution would be 33 fps, another would be 36fps. Maybe something to do with thread scheduling?
AMD 64 x2 4200+
2gb ram
1.6 client vm
winxp
v8: 33fps@88%
v10: 35fps@95%
(Guess my ram is faster than Martin’s.)
edit:
1.6 server vm
v8: 46fps@85%
v10: 50fps@91%
Server VM pretty much lives up to expectations then eh?
Cas
12.5 fps for exe
9.5 fps for jar (client jvm)
yup about 30% faster
jvm 1.6.03
cpu XP2000 1.6ghz
gpu ati x800
ram 768MO
Thanks for all your testing!
That is a surprising difference between the server and client jvms. Did i read some where that sun was thinking of making a jvm in which effectively the client jvm will be as good as the server jvm and thus just the one jvm?
Hmm, 175% is not bad… still better than the previous version. There are still parts of the program which are not parallerised some of which can not ever be but some which can however it does not make sense to do so until i implement a bounding volume heirachy.
So I am aiming to achive 190% utilisation.
About the FPS per run on version 10, i have changed the fps counter to use a smoothing average. For the first 3 seconds it uses the instant fps. However after 3 seconds it uses the following formula:
avgFPS= (prevAvgFPS*2+currentFPS)/3
perhaps this is causing the difference between versions? I am not sure why it would… all it will do is be less responsive to reflect change in fps.
Version8:
Client-jvm:
30fps - ~170% load
Server-jvm:
46fps - ~170% load
You should check for thread problems in your code, starting your app with -Xint gives me sometimes a wrong window-size.
Are you doing all modifications to Swing/AWT-Components on the EDT?
Core2Duo T7200 laptop, 2ghz
jdk1.7.0 build22
The JFrame and components are created and setup in the constructor of sub class of JFrame. The frame and its components are never modified at any other point in the program.
A buffered image is drawn onto a back buffer of a BufferStrategy and then flipped to be viewable.
The flipping does not occur on the EDT. but i thought that it was not necessary with BufferStrategy you are determining when to “paint”… is this not the case?
[quote]The JFrame and components are created and setup in the constructor of sub class of JFrame. The frame and its components are never modified at any other point in the program.
[/quote]
This could be the problem, and I guess it maybe is the root of the problem on my machine.
You create the JFrame and your components on the main-thread, not on the EDT. This is a violation of Swing’s threading rules, and it is best-practise to even do component setup in the EDT.
The rendering itself can be done by any thread, because as far as I know all Java2D-related stuff is thread-safe.
lg Clemens
Really?! All these years I have been doing it incorrectly… Can you point me to an approriate example/tutorial? All the examples i have seen on the Swing Tutorial have the components set up in the main thread… e.g. http://java.sun.com/docs/books/tutorial/extra/fullscreen/example-1dot4/DisplayModeTest.java
It should be completely possible to construct and assemble Swing components in any thread. What you can’t do then is diddle with them or act on events in any thread.
Cas
Ah, I think i know what the problem is…
In order to get the frame’s inset information, the frame has to be be set visible. I then re-size the frame based on these inset information. Is there a way of obtaining the frame’s decoration dimensions before making it visible? Failing that I will put the re-size code in a swing worker to be performed by the EDT
I think you can get the decoration dimensions after you call addNofity() on the frame.
I believe that restriction was relaxed some time ago. You can construct away and fiddle all you like until the components are actually realised on the screen.
Cas
I found quite different results - it seems like they said some time ago that that its ok until you realize the component, but now the consensus seems to be to do everything on the EDT.
Its no problem after all, so what is the downside of doing it like recommended and beeing on the safe side?
lg Clemens
Thanks! didnt know about that. It seems to have done the trick.
Did you made any progress on this? Is spawning code in a new thread enough to have it executed on different cores?
yes and no… i am achieving about 175%-180% utilisation. however without removing a barrier wait. i have been focusing on other aspects of the engine lately.