Does Java use hardware acceleration when drawing if it is available? If it doesn’t normally, are there ways of accessing it?
I’d love to program my games in Java, and I think I can handle the slowdown of about 50% that Java is supposed to have vs. C++, in exchange for its being so much easier to code in and so much more portable…but if accellerated blending isn’t available, that means a lot more than just 50% slowdown.
It does on Windows in 1.4, and Linux in 1.5, and Mac in 1.3 but not 1.4…
All of this is behind the scenes. The runtime will try to manage the images for you and do the right think most of the time. In 1.4 it will do this as long as you make sure your image is a ‘compatible’ image. Eg. after loading stamp the image into an image created with createCompatibleImage();
[quote]I think I can handle the slowdown of about 50% that Java is supposed to have vs. C++, in exchange for its being so much easier to code in and so much more portable…but if accellerated blending isn’t available, that means a lot more than just 50% slowdown.
[/quote]
The slowdown in raw code is not near 50%… depending on what you do and how you do it, the speed of Java code execution is generally on par with C. As you have guessed it is usually other limitations - such as the ability to accelerate images with hardware that make the difference for games. software blits in Java will be slower than in C… because of the Java safety checks like array bounds checking, inability to exploit pointer tricks, etc… Also any sane software blit should be done with MMX/SSE/SSE2 or Altivec instructions, but I doubt the any current Java runtime does this.
Scott is a hopeless optimist about performance 
Reckon on 50% being a good baseline for typical performance. Also reckon on hardware acceleration being a little primitive. If you want performance, stability, cross-platformity and reliability try LWJGL Tiny payload, mucho speedo.
Cas
[quote].but if accellerated blending isn’t available, that means a lot more than just 50% slowdown.
[/quote]
It isn’t. Or rather, it might be, if you just happen to be running the right combination of VM, OS, hardware and command line flags. But don’t count on it.
Use LWJGL and be happy
[quote]Scott is a hopeless optimist about performance Reckon on 50% being a good baseline for typical performance.
[/quote]
Well I’m serious about 50% being too low… I haven’t seen many examples that go down as far as 50%. Usually only special cases perform that bad. It’s been my experience that the graphics are the biggest factor.
No arguments about using an OpenGL binding to get past the graphics slowdowns though. Keeping all the graphics bits just right so that the JRE acceleration works for you is a pain, and I don’t claim that you can always get the speed you need just by making sure your images are accelerated by the JRE.
[quote]Also any sane software blit should be done with MMX/SSE/SSE2 or Altivec instructions, but I doubt the any current Java runtime does this.
[/quote]
Not that it helps, but we do use VIS instructions on sparc.
You see now the need for a SIMD instruction generator in the JVM now 
? Wrap the four major SIMD instruction sets up (MMX, SSE, SSE2, Altivec) and execute directly on a DirectByteBuffer.
Cas
[quote]Not that it helps, but we do use VIS instructions on sparc.
[/quote]
Heh, do you guys still do a Sparc JVM then? 
;D
Yeah, I doubt much blitting is happening on a Sparc server. At least compared to games running on Intel or PPC.
I’ve whined about this to Sun on more than one occasion. The JPEG encode/decode should be done with tuned MMX/SSE/SSE2 instructions - you can get libraries from Intel for free* that already adapt to the processor and contain highly tuned code for this stuff.
http://developer.intel.com/software/products/perflib/ijl/
Basically the idea is that the if you have decided to go to native code for key pieces of the JRE (JPEG codec), then at least have a native implementation that doesn’t suck (cough current Java JPEG codec cough) and is orders of magnitude slower than it could be if done properly.
For something like blitting in general it is never possible to make it ‘fast enough’ the best you can get is ‘as fast as is possible’.
[quote]Scott is a hopeless optimist about performance Reckon on 50% being a good baseline for typical performance.
[/quote]
PC is a hopeless pessimist. Reckon on 90%+ if you are willing to properly tune your code and aren’t doing things thatbvery specifically hit Java’s weakest areas.
(IE if you absolutely HAVE to psend 90% of your processing time doing array buble sorts then I’d buy 50%).
Isnt it nice how we all have our opinions? AND we all have data to back it up. In particular, I’d guess Cas’s experience probably has a LOT to do with arrays as he’s a 3D juggler. My expreience has to do with a sort of average of a braod range of problems because I spent about 2 years on the JDK tuning team doing both JDK APis and outside customers’ code.
In the end, give it a chance, learn how to do Java right and tune Java right, and then you TOO will have an opinion
[quote]Basically the idea is that the if you have decided to go to native code for key pieces of the JRE (JPEG codec), then at least have a native implementation that doesn’t suck (cough current Java JPEG codec cough) and is orders of magnitude slower than it could be if done properly.
.
[/quote]
Question, can’t you plug-in your own codec into the imageio framework? I bet if you did an example that was lots faster and justa s high quality as the one in the JDK and sent it in to thsoe guys it woudl geta lot of attention…
… or, you can use the jpeg imageio codec from JAI, it’s highly optimized native code, as I understand. See if it helps.
You can get 90-100% of C++ speed using the server VM Trouble is, no-one has it - and the client VM is typically around 50% across the board of a like-for-like real world C++ application with no other obvious bottlenecks.
Jeff, please please please start nagging those VM guys to merge the VMs!
Cas
[quote]… or, you can use the jpeg imageio codec from JAI, it’s highly optimized native code, as I understand. See if it helps.
[/quote]
[rant]Could someone explain why Sun has more than one JPEG codec?[/rant]
I can’t use ImageIO in my application because:
A) It has a memory leak if I reuse the image reader
(fixed in Tiger yay!: http://developer.java.sun.com/developer/bugParade/bugs/4868479.html)
B) If I don’t reuse the image reader OR I call certain reset methods that work around the leak, it’s performance plummets and it generates massive garbage. (See workarounds and evaluation for above bug)
That has forced me to go back to the awt toolkit image loader with it’s abysmal performance.
[rant]Here we complain about JRE size, and it is full of this bloat, with redundant implementations of image loaders. Replace the old loaders with calls to ImageIO behind the scenes… maybe then the ImageIO bugs will be important enough to fix and everyone will be happy! Maybe this has been done for Tiger?[/rant]
[quote]Replace the old loaders with calls to ImageIO behind the scenes… maybe then the ImageIO bugs will be important enough to fix and everyone will be happy! Maybe this has been done for Tiger?
[/quote]
Funny you should say that.
It was attempted to be done for tiger, but, unfortunately, we found that
So, due to the time constrants we had to abandon this idea for tiger, and instead clean up imageio implementation first and try again in the future release…
Yes, I can see that it might matter for a huge animated GIF, but I bet it would solve more problems than it caused if image loading was simply not asynchronous. It should never have been asynchronous in the first place really. The few that want it that way could start their own thread and managed it in their code. Then for the majority they could avoid all the pain with media trackers, etc.
Thanks for trying though
It is nice to see ImageIO cleaned up.
Thanks for all the info…I’ll take it I can expect a Java program to run somewhere between 90% and 50% of the speed of C++, and I’ll be sure to get the latest version of LWJGL when I’m ready to get started coding…I still have a fair bit to learn before I’ll really be ready to take on coding my side-scroller, but it’s good to hear I’ll be able to write a game with little noticable slowdown outside of the attrocious loading time everything Java seems to have…I may actually be able to use what I’m learning, rather than just using it as a stepping-stone to C++.
Of course, it’s possible the horrible loading times I’m getting is because Eclipse is so bloated…bloated with truly useful features, but still bloated…whatever the cause, it sometimes takes two minutes for one of my console programs to start running…once it runs, it finishes instantly, but it’s a pain to wait two whole minutes while the VM loads.
[quote]it sometimes takes two minutes for one of my console programs to start running…
[/quote]
Something is broken on your machine. I load entire application servers (i.e. Weblogic) in less than 60 seconds.
God bless,
-Toby Reyelts
Probably not broken… Eclipse is very big… and it might be configured to refresh and rebuild the workspace on startup too.
Hey, by the way, loading time in 1.5 is really much, much faster than 1.4 now! I’m very pleased to see progress in this area. There’s also a 10mb saving per VM instance
Cas
Likely Eclipse is eating all your memory and youa re swapping trying to run your app.
Swapping in general really hurts Java performance and it absolutely kills it dead under Winblows.
A hint, watch for that tell tale red drive light. If its glowing like a stop light then you are likely swapping.