I’m the kind of person that likes to understand what makes things tick, evidenced by the drawer of torn apart electronics under my bed. So anyway, what is it that makes Java2D such a slow way of rendering? And conversely, what makes other libraries more efficient? And why can’t I do directly what any libraries do, so I can cut out the middle man and make things as streamlined as possible for the specific purpose?
Java2D uses the CPU to draw, LWGJL uses OpenGL, which utilizes the graphics card.
And, you can do directly what the libraries do. Someone had to right them, didn’t they?
In order to abstract the nature of drawing graphics the Java2D API hides all the guts of OpenGL and the graphics pipeline. So instead of working with vertex arrays, VBOs, textures, etc. you can happily work with lines, pixels, strings, and images.
Java2D will attempt to optimize things at first (e.g. images will be managed initially i.e. stored in the graphics card’s memory). But you can’t have endless arbitrary images and perform pixel manipulations via a high level API before one hits the limits of what a graphics card can handle. Once you do then it’s slows-ville (primarily because you’re now transferring data between main memory and the graphics card for each frame). It would be impossible to recover from this without exposing the nuts and bolts of the graphics pipeline which an API can’t do without losing its integrity.
Also Java2d places image quality and accuracy at the top of it’s priorities - the same code will generate nearly exactly the same image regardless of platform or graphics hardware.
OpenGL allows a certain amount of slack for better performace. For example when you draw a triangle, exactly which pixels along the edge will be filled is not precisely defined. For games this really doesn’t matter, as long as it’s consistent, so we see j2d being ‘slow’ because it’s worrying about something we don’t care about.
This is also why when j2d is using OpenGL under the hood it’s still (usually) slower than calling GL directly.
Whenever I’m lazy and use Java2D, I limit myself to the following:
- disable hardware acceleration entirely, pure software pipeline
- only use OPAQUE and BITMASK images (createCompatibleImage())
Basically create the situation as it was before Java 6 update 10. Performance is quite stable then as you don’t have any difference in behavior across systems and hardware. For my retro game remaking purposes that works just fine. But as soon as you want to do something that games of 20-25 years ago did not do (rotate, scale, alpha blend, whatever), you should immediately forget about Java2D entirely.
Curious, what would be an efficient way of accomplishing these things in Java now that Slick has been discontinued?
JediSange, see LibGDX. Pretty excellent library, much more powerful than Slick, much better optimized, and also ports to a variety of platforms (iOS, Android, WebGL).
I think this excellent tutorial:http://www.java-gaming.org/topics/java2d-clearing-up-the-air/27506/msg/0/view/topicseen.html#new is exactly what you are looking for, if you want to use Java2D as efficiently as possible.
Actually, there have been several attempts of creating high level libraries with the same design than Java2D but with a better hardware acceleration, for example a part of GTGE simulates Java2D.