Bishop
Junior Newbie
Java games rock!
|
 |
«
Posted
2003-06-04 02:10:50 » |
|
I have recently got a new Mac and have been disappointed to find that a game I have been working on is much slower than it was on my PC. I have downloaded a few games from these forums a Mortal Kombat clone, a tile based scrolling map example and the following sample app http://www.pkl.net/~rsc/Balls.jarand while all behave beautifully on my PC they are shockingly slow under OS X. It seems that it may be related to fullscreen exclusive mode as my game maps scroll at a similar speed to my PC in the map editor but not in fullscreen mode and the sample app Balls.jar runs fine in windowed mode as well. Has anyone else experienced this when trying a fullscreen game on OS X? Is fullscreen exclusive mode fully supported on OS X? Thanks in advance.
|
|
|
|
mattocks
Senior Newbie 
Java games rock!
|
 |
«
Reply #1 - Posted
2003-06-04 03:53:49 » |
|
What type of graphics images are being displayed? This is often system/video dependent. Try running this performance test on both platforms:
// Program : TestGraphics.java // Description: Test performance of graphics types. // Notes : Use 'java -Xcomp' to run this app. This option will // force JIT-compilation at startup, instead of letting // HotSpot decide when and what to compile. Without it, // HotSpot may trigger compilation at an unknown or // unexpected point, invalidating the elapsed times due // to a flurry of JITC-ing. It may also be useful to run // with -Xint and -Xmixed to show how much is interpreter // cost and how much is graphics rendering cost.
import java.awt.*; import java.awt.image.*;
public class TestGraphics { static final int WIDTH = 700, HEIGHT = 700;
static final int COUNT = Math.min(WIDTH,HEIGHT)/2;
static final String[] sImageNames = { "TYPE_INT_RGB (HotSpot warm-up, throw away)", "TYPE_INT_RGB", "TYPE_INT_ARGB", "TYPE_INT_ARGB_PRE", "TYPE_INT_BGR", "TYPE_3BYTE_BGR", "TYPE_4BYTE_ABGR", "TYPE_4BYTE_ABGR_PRE", "TYPE_USHORT_565_RGB", "TYPE_USHORT_555_RGB", "TYPE_BYTE_GRAY", "TYPE_USHORT_GRAY", "TYPE_BYTE_BINARY", "TYPE_BYTE_INDEXED", "native CompatibleImage" };
static final int[] sImageConstants = { BufferedImage.TYPE_INT_RGB, BufferedImage.TYPE_INT_RGB, BufferedImage.TYPE_INT_ARGB, BufferedImage.TYPE_INT_ARGB_PRE, BufferedImage.TYPE_INT_BGR, BufferedImage.TYPE_3BYTE_BGR, BufferedImage.TYPE_4BYTE_ABGR, BufferedImage.TYPE_4BYTE_ABGR_PRE, BufferedImage.TYPE_USHORT_565_RGB, BufferedImage.TYPE_USHORT_555_RGB, BufferedImage.TYPE_BYTE_GRAY, BufferedImage.TYPE_USHORT_GRAY, BufferedImage.TYPE_BYTE_BINARY, BufferedImage.TYPE_BYTE_INDEXED };
// This is a simple test that does setColors and fillRects static void recTest(BufferedImage bi) { Graphics g2D = (Graphics2D) bi.getGraphics(); for (int i=0; i<COUNT; i++) { if (i%2 == 0 ) { g2D.setColor(Color.black); } else { g2D.setColor(Color.red); } g2D.fillRect(i,i, WIDTH-i,HEIGHT-i); } }
public static void main(String[] args) { long startTime; long[] elapsedTime = new long[sImageConstants.length + 1];
// Allocate 14 different buffered images to cross-compare BufferedImage[] bis = new BufferedImage[sImageConstants.length + 1]; for (int i=0; i<sImageConstants.length; i++) bis = new BufferedImage(WIDTH, HEIGHT, sImageConstants);
// Include native type: bis[sImageConstants.length] = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration().createCompatibleImage(WIDTH, HEIGHT);
// Compute and print performance System.out.println("Simple Graphics Performance Example"); System.out.println("Time\tImage Type\n----\t----------"); for (int i=0; i<=sImageConstants.length; i++) { startTime = System.currentTimeMillis(); recTest(bis); elapsedTime = System.currentTimeMillis() - startTime; System.out.println(elapsedTime + "\t" + sImageNames); }
// Doing graphics may start the AWT event-thread, thereby preventing // a return from main() from causing an exit. So, always force an exit. System.exit(0); } }
|
|
|
|
Bishop
Junior Newbie
Java games rock!
|
 |
«
Reply #2 - Posted
2003-06-04 06:36:54 » |
|
Thanks I have run the TestGraphics app on both systems and here are the results.
---PC--- Simple Graphics Performance Example Time Image Type ---- ---------- 859 TYPE_INT_RGB (HotSpot warm-up, throw away) 828 TYPE_INT_RGB 813 TYPE_INT_ARGB 828 TYPE_INT_ARGB_PRE 828 TYPE_INT_BGR 609 TYPE_3BYTE_BGR 813 TYPE_4BYTE_ABGR 828 TYPE_4BYTE_ABGR_PRE 375 TYPE_USHORT_565_RGB 375 TYPE_USHORT_555_RGB 109 TYPE_BYTE_GRAY 360 TYPE_USHORT_GRAY 468 TYPE_BYTE_BINARY 110 TYPE_BYTE_INDEXED 828 native CompatibleImage
---Mac--- Simple Graphics Performance Example Time Image Type ---- ---------- 1220 TYPE_INT_RGB (HotSpot warm-up, throw away) 459 TYPE_INT_RGB 519 TYPE_INT_ARGB 478 TYPE_INT_ARGB_PRE 467 TYPE_INT_BGR 498 TYPE_3BYTE_BGR 465 TYPE_4BYTE_ABGR 463 TYPE_4BYTE_ABGR_PRE 196 TYPE_USHORT_565_RGB 163 TYPE_USHORT_555_RGB 121 TYPE_BYTE_GRAY 90 TYPE_USHORT_GRAY 106 TYPE_BYTE_BINARY 480 TYPE_BYTE_INDEXED 463 native CompatibleImage
The PC is running a GForce2 mx and the Mac has an ATI Radeon 9000.
I have tested a quick example whith no images and just an animated filled rectangle and the performance is still bad with OS X in fullscreen.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Mark Thornton
|
 |
«
Reply #3 - Posted
2003-06-04 08:21:16 » |
|
That test program doesn't measure the time required to copy the image to the graphics device.
|
|
|
|
Abuse
|
 |
«
Reply #4 - Posted
2003-06-04 08:45:24 » |
|
yeah, the test program is just measuring the speed at which the different image types can be altered. (The results are still interesting, though not relevant to the issue of hardware acceleration or fullscreen)
|
|
|
|
lilspikey
Senior Newbie 
Computers Stole My Social Skills
|
 |
«
Reply #5 - Posted
2003-06-04 16:26:01 » |
|
Surprised by that. I haven't got OS X yet, but the fact that the problem is in seems to be in fullscreen only is a bit worrying. Have you tried the mailing list archives on apples developers site?
http://lists.apple.com/mailman/listinfo/java-dev
From what I understand it should just be the standard cocoa classes to achieve fullscreen, so maybe it's a miss configuration when setting up fullscreen. Do the apps you have tried just use the existing resolution/bitdepth or try and impose new ones?
|
|
|
|
swpalmer
|
 |
«
Reply #6 - Posted
2003-06-04 18:00:21 » |
|
There are definately some speed issues with image blitting in Java on OS X. File a bug report with Apple.
For me Balls.jar doens't do so hot in windowed mode either.. how many balls did you have going? For me it degrades much faster than on the PC as more balls are added.
Also from the timings above byte indexed images (GIFs) are going to be much slower for somethings than other image types. It would probably be best (for PC and Mac) to make sure the images are copied to the native image format when they are loaded.
|
|
|
|
Bishop
Junior Newbie
Java games rock!
|
 |
«
Reply #7 - Posted
2003-06-04 22:39:46 » |
|
For me Balls.jar doens't do so hot in windowed mode either.. how many balls did you have going? I actually tried Balls.jar on a friends Powerbook and it ran at about 8 to 12 fps straight off from the first ball animated as opposed to 25 to 30 fps when in windowed mode. Do the apps you have tried just use the existing resolution/bitdepth or try and impose new ones? Both, some changed the resolution and bit depth but I have tried using the current display mode and get the same behaviour. To me this really seems to be related to fullscreen exclusive mode and not just image types. I have looked at the apple java-dev mailing list but I can barely find any mention of fullscreen exclusive mode at all except someone asking when 1.4 will be available for OS X so he could try it out. Im really hoping this means that other people arent getting this problem and that there is something I can do about it. 
|
|
|
|
Abuse
|
 |
«
Reply #8 - Posted
2003-06-05 08:11:25 » |
|
I actually tried Balls.jar on a friends Powerbook and it ran at about 8 to 12 fps straight off from the first ball animated as opposed to 25 to 30 fps when in windowed mode.
Both, some changed the resolution and bit depth but I have tried using the current display mode and get the same behaviour.
To me this really seems to be related to fullscreen exclusive mode and not just image types.
Is DisplayMode switching supported in fullscreen on OSX? (In Balls.jar I think I assumed it would always be supported, so it might fall over on a platform that doesn't support it  ) Either way, it sounds to me like there is no hardware acceleration going on at all - without a mac, its kinda hard to be sure though  Is their a setProperty flag that disables all hardware features? (Acceleration, fullscreen etc etc) It'd be the eziest way for me to check what Balls.jar does on machines that don't support fullscreen  :edit: btw, that was a shoking old version of Balls.jar - I've just updated it now  This version has tonnes of new features, as well as working windowed mode<->fullscreen switching!! (Its a massive hack, just have a look at GameFrame.java to see how its done  )
|
|
|
|
swpalmer
|
 |
«
Reply #9 - Posted
2003-06-05 12:22:39 » |
|
Just tried the latest Balls.jar on my PowerBook 1GHz, ATI Radeon....
It does not exit when you press Esc.. the full screen display is simply 'stuck' - I had to kill the process.
All tests were triple buffered 32 bit...
At max res 1280x854 fullscreen I got between 6 and 7 frames per second WITH 0 BALLS
1024 x 768 WINDOWED mode got 15 FPS with 0 balls 1024 x 768 FULLSCREEN mode was 8-9 FPS with 0 balls
Yep, fullscreen seems to be sucking more than windowed mode.. but let's not forget that the windowed mode SUCKS BIGTIME too.
Switching the fullscreen display resolution from fullscreen mode locked up the app.
800 x 600 windowed mode kept cycling the # of balls and would not stabilize??
|
|
|
|
Games published by our own members! Check 'em out!
|
|
Abuse
|
 |
«
Reply #10 - Posted
2003-06-05 12:40:38 » |
|
Just tried the latest Balls.jar on my PowerBook 1GHz, ATI Radeon....
It does not exit when you press Esc.. the full screen display is simply 'stuck' - I had to kill the process. ye gads, the OSX JVM sucks big time  The 'esc' not quitting is abit disturbing - sounds to me like a bug in the APIs somewhere, cos the code definitly adds a key listener to both frames (As a work around for frame.setUndecorated() breaking bufferStrategy, i've used 2 frames, 1 for windowed, 1 for fullscreen) All tests were triple buffered 32 bit...
At max res 1280x854 fullscreen I got between 6 and 7 frames per second WITH 0 BALLS
1024 x 768 WINDOWED mode got 15 FPS with 0 balls 1024 x 768 FULLSCREEN mode was 8-9 FPS with 0 balls low fps at high resolutions sounds to me like the back buffers arn't being created in vram at all. So there realy isn't any HW acceleration in OSX 
Yep, fullscreen seems to be sucking more than windowed mode.. but let's not forget that the windowed mode SUCKS BIGTIME too.
Switching the fullscreen display resolution from fullscreen mode locked up the app.
changing display mode while in fullscreen crashes it, huh? but, u can start it up in different display modes fine? sounds like its not releasing the old frame buffer, before creating the next 1. That sometimes happens in the Win JVM as well, its shitty coding by Sun IMO. damn it Sun, get your act together :/ 800 x 600 windowed mode kept cycling the # of balls and would not stabilize??
@low fps, it will never stablise properly... Gonna change the way balls are added to fix that. In my defence, when it all works properly, (and you get a decent fps) the ball adding code works fine  I get 7000ish bitmasked balls at 30fps on a 1.33gig athlon with gf2 (under win98)
|
|
|
|
mattocks
Senior Newbie 
Java games rock!
|
 |
«
Reply #11 - Posted
2003-06-05 17:46:03 » |
|
AFAIK, hardware acceleration isn't fully implemented yet.
Longshot -- have you tried passing the runtime flag:
-Dcom.apple.awt.hwaccel=true
?
|
|
|
|
leknor
|
 |
«
Reply #12 - Posted
2003-06-05 20:37:15 » |
|
|
|
|
|
max_power
Junior Newbie
Java games rock!
|
 |
«
Reply #13 - Posted
2003-06-06 05:21:55 » |
|
I just wanna say that I have the same problem with the thing I'm doing. (Show and scroll a map from .png)
Mac OSX: Fast compiling, real slow running (PB G4 867, 768 MB, Radeon 9000 mobility) Win ME: Slow compiling fast running (Athlon 1 GHz, 512 MB RAM, Geforce 2mx)
It's a shame...
|
|
|
|
swpalmer
|
 |
«
Reply #14 - Posted
2003-06-06 12:24:21 » |
|
Actually, as I understand it, on OS X 'managed' (formerly 'automatic') images are definately not supported.. and I suspect that volatile images are not in VRAM either... What freaks me out is how the performance can still be so bad.. 7 FPS to draw a few lines of text on the screen really blows even if the back buffer isn't in VRAM... we are talking about a system that can playback fullscreen MPEGs faster... decoding MPEG takes a tad more CPU processing than drawing a few balls or lines of text.. forget hardware blits...
|
|
|
|
princec
|
 |
«
Reply #15 - Posted
2003-06-06 22:24:01 » |
|
Better get that bloody port workin' then eh?  Then we'll make the bugger's eyes water. Cas 
|
|
|
|
lilspikey
Senior Newbie 
Computers Stole My Social Skills
|
 |
«
Reply #16 - Posted
2003-06-07 07:57:47 » |
|
Funny really considering one of the things that looked cool about MacOS X Java was that Swing was hardware accelerated. If they are accelerating Swing, how come "automatic" images aren't there/accelerated?
I wonder whether this is a similar problem to the AWT-Thread bug? Anyone tried profiling to see what the apps are really doing?
Also for the Esc key thing, could it be a focus problem? That's usually the first thing I look for when my keys don't work in an app.
John
|
|
|
|
swpalmer
|
 |
«
Reply #17 - Posted
2003-06-07 20:21:02 » |
|
I just thought I would point out an interesting observation that I hadn't noticed before. BufferCapabilities methods isPageFlipping and isMultiBufferAvailable both return FALSE on Mac OS X.  If I understand this, it means that there can only be at most one back buffer and that the contents of the back buffer are copied to the primary surface with a blitting operation. What i don't get is this comment from the Fullscreen tutorial, "For best results, create your buffer strategy on a full-screen exclusive window. Make sure you check the isFullScreenRequired and isPageFlipping capabilities before using page-flipping." Doesn't the buffer strategy do page flipping or blitting when you call show() and you have no direct control of which will be happening anyway? What are you supposed to do with the result of isPageFlipping()  ? According to http://java.sun.com/docs/books/tutorial/extra/fullscreen/example-1dot4/CapabilitiesTest.java the backbuffer is accelerated(?), but nothing else is checked.. No Accelerated images, or front buffer, not volatile capabilities, full screen is not required etc.. Seems that the Mac 1.4 implementation kind of stinks for this tuff.. which is a shame.
|
|
|
|
lilspikey
Senior Newbie 
Computers Stole My Social Skills
|
 |
«
Reply #18 - Posted
2003-06-08 13:22:46 » |
|
This isn't related to the fact the everything in OS X is double buffered for free is it? Haven't really used fullscreen stuff much yet, but does that mean that you could make a BufferStategy with one buffer (e.g. createBufferStrategy( 1 )) and it would be double buffered on OS X? The only trouble is I'm not sure how you'd detect you were on OS X (short of System.getProperty( "os" )).
|
|
|
|
|
princec
|
 |
«
Reply #20 - Posted
2003-06-09 16:16:10 » |
|
I think you're cutting your noses off to spite your face over this. Code it for Java, to work fast on Windows. That's one of the main reasons why you're using Java I hope - to get as many computers running your software as possible. This means that to create a net balance of happiness, make the Windoze people happy first, and then complain to Apple a lot about the performance problem in MacOSX. They'll listen; AIUI they've been fixing performance problems constantly in OSX. Cas 
|
|
|
|
swpalmer
|
 |
«
Reply #21 - Posted
2003-06-09 18:24:45 » |
|
I'm only whining because I want to do stuff on my laptop (Powerbook)... from the marketing aspect.. you're right.
|
|
|
|
Mojomonkey
|
 |
«
Reply #22 - Posted
2003-06-09 18:59:04 » |
|
While I can appreciate what you are saying Cas, I think you are a little off. Code for your target, which typically is the machine you are on and use yourself (which in most cases is Windows). In this case, swpalmer is a OS X user and he is disappointed, feeling like he can't use his platform of choice. Not everything is a cut and dried marketing scheme, sometimes you are just doing things for yourself.
|
Don't send a man to do a monkey's work.
|
|
|
swpalmer
|
 |
«
Reply #23 - Posted
2003-06-09 21:40:21 » |
|
Well, yes that's basically it... I mean I have a fairly spiffy windows box at work, and a broken one at home.. so I'm not totally out of luck... But I can't run any Java applications (that use Swing) on my home machine because they lock the machine up instantly whenever they try to do something with direct draw. (I know I can turn that off). Basically the machine doesn't support graphics cards (seriously - that's what the Tyan support guy ended up admitting).
|
|
|
|
princec
|
 |
«
Reply #24 - Posted
2003-06-09 22:16:35 » |
|
Well, that's exactly what I mean by cutting your nose of to spite your face  A good moan to Apple is the only thing that can really help in the long run, or you'll forever be stuck in the same situation. Cas 
|
|
|
|
swpalmer
|
 |
«
Reply #25 - Posted
2003-06-17 10:59:21 » |
|
Trust me the message has been delivered to Apple, and I do expect that they are working on it. They were just so late with their 1.4.1 implementation that they did the logical choice of ... get it out as fast as possible, THEN optimize it. I can't really blame them for that strategy...but it doesn't make it any less frustrating  . Overall I think Apple has a great commitment to the Java platform... but it's not like they have the resources of Microsoft to dump on it.
|
|
|
|
lilspikey
Senior Newbie 
Computers Stole My Social Skills
|
 |
«
Reply #26 - Posted
2003-06-28 17:51:06 » |
|
"For best results, create your buffer strategy on a full-screen exclusive window. Make sure you check the isFullScreenRequired and isPageFlipping capabilities before using page-flipping."
Doesn't that just mean you have to be in full screen mode before you check out those capabilities? I know it is the case for isDisplayChangeSupported. I hadn't realised until moving from Linux - which always returns false - to testing on a Windows box and still not going into fullscreen. In the meantime you could try using the quicktime for java stuff to go in to Fullscreen mode. It might give you better performance, although if it does it makes you wonder what apple have done to mess up performance in 1.4. You want to check out the class FullScreenWindow (can't remember the package off hand). Although whilst trying to find the javadoc for it, I read that QT for java is only supported in 1.3, and not in 1.4. So to use it you'd have to run 1.3. I guess it's classic Apple, not being overally concerned with backwards compatibility.
|
|
|
|
|