Yeah, that is going to be slow.

The code is using the CPU to copy all the images and not using any hardware acceleration. You have a memory buffer with images in it writing to other memory buffers with images in them.

When you do all that processing everything must go through the CPU. That means the data must be loaded into the CPU cache replacing other things that are there -- like your program's data. The CPU needs to churn through all the rendering code, with the images sizes you are mentioning it sounds like it is processing about 30MB worth of data. Note that 3GHz@60fps = 50 million cycles per frame, so even in an ideal world you have burnt over half your compute cycles by manually copying images. Then the updated image gets transferred out to the video card for display. Contrast this with using the GPU for all of that copying, your program stays running in the CPU all the time and there are no significant image processing going on. The GPU is designed to handle a hundred million pixels per 60fps frame easily.

Assuming you are on a PC and not an Android device (they are also written with Java) look up JOGL, the Java OpenGL interface. Everything you need is under javax.media.opengl.*.

There are many JOGL tutorials on the web, they cover it pretty well.

Assuming you are on a PC and not an Android device (they are also written with Java) look up JOGL, the Java OpenGL interface. Everything you need is under javax.media.opengl.*.

So from what I am understanding, it uses the CPU by default for loading image and running the game unless I make it explicitly I want to use hardware acceleration from standard pure Java?

I see. Would I be at a disadvantage if I do not have any knowledge on OpenGL? Is that really true?

This source says "This allows computer graphics programmers to use the object-oriented tools for Java with hardware-accellerated 2D and 3D graphics while leveraging their existing knowledge of OpenGL."

Source: http://www.cs.umd.edu/~meesh/kmconroy/JOGLTutorial/

It might use hardware acceleration, or it might not, The problem is that the decision often seems random and it can change mid-execution, and you have no way to detect or control the situation. Sometimes you get lucky, sometimes you get unlucky, and it is extremely difficult for the program to know until it is too late.

Some of the java graphics parts will take advantage of 2D hardware acceleration. Unfortunately they are tricky to get correct and they don't document which operations prevent the acceleration. That's why the general advice is to use JOGL or another library that ensures hardware acceleration.

Sometimes it decides to use OpenGL or DirectDraw graphics operations to accelerate it, sometimes it uses a very slow CPU processing to do the exact same operation. Sometimes one operation is accelerated but another is not, perhaps on one machine drawImage() is not hardware accelerated but copyArea() is accelerated. Then on the next machine drawImage() may be accelerated but copyArea is not. You never know what you are going to get.


JOGL is a wrapper for OpenGL. Using JOGL or one of the other similar libraries give much better results because you are no longer at the undocumented whims of the system. If you rely on Java's BufferedImage you get some of the benefits like streaming support, but it comes at a cost that it may be high performance or low performance at the system's whim, sometimes changing performance characteristics mid-use when an operation like GetRGB() is used. Contrast this with an OpenGL texture where you know it is a texture, and it has all the performance characteristics that come with it.

It might use hardware acceleration, or it might not, The problem is that the decision often seems random and it can change mid-execution, and you have no way to detect or control the situation. Sometimes you get lucky, sometimes you get unlucky, and it is extremely difficult for the program to know until it is too late.

Some of the java graphics parts will take advantage of 2D hardware acceleration. Unfortunately they are tricky to get correct and they don't document which operations prevent the acceleration. That's why the general advice is to use JOGL or another library that ensures hardware acceleration.

Sometimes it decides to use OpenGL or DirectDraw graphics operations to accelerate it, sometimes it uses a very slow CPU processing to do the exact same operation. Sometimes one operation is accelerated but another is not, perhaps on one machine drawImage() is not hardware accelerated but copyArea() is accelerated. Then on the next machine drawImage() may be accelerated but copyArea is not. You never know what you are going to get.


JOGL is a wrapper for OpenGL. Using JOGL or one of the other similar libraries give much better results because you are no longer at the undocumented whims of the system. If you rely on Java's BufferedImage you get some of the benefits like streaming support, but it comes at a cost that it may be high performance or low performance at the system's whim, sometimes changing performance characteristics mid-use when an operation like GetRGB() is used. Contrast this with an OpenGL texture where you know it is a texture, and it has all the performance characteristics that come with it.

Wow so even using JOGL can produce randomness in the methods?

I never knew I was at the hands of the system for using all parts of Java. I thought that only happens when I needed to use Java's paintComponent method.

So I am still at the mercy of the operating system even though I am doing my own painting. Things just got even more interesting.

It might use hardware acceleration, or it might not, The problem is that the decision often seems random and it can change mid-execution, and you have no way to detect or control the situation. Sometimes you get lucky, sometimes you get unlucky, and it is extremely difficult for the program to know until it is too late.

Wow so even using JOGL can produce randomness in the methods?

I never knew I was at the hands of the system for using all parts of Java. I thought that only happens when I needed to use Java's paintComponent method.

So I am still at the mercy of the operating system even though I am doing my own painting. Things just got even more interesting.

Sorry for being unclear on that.

The "it" in the quotation was referring to Java draw calls. When you use Java's drawing system everything is handled by the Java implementation. They have a history of erratic performance. There is no way for the program to force the implementation to do anything. The erratic and sometimes painfully slow performance of the built in drawing libraries is one of many reasons that games will usually use a library that is written with performance in mind. As mentioned in the link, sometimes just resizing a window or moving it between monitors on a multi-monitor system can cause the built in functions like drawImage to dramatically change behavior.

When you use a library like JOGL, you are relying on the behavior of the library instead of the behavior of the Java implementation. The key difference is that JOGL and similar libraries have a focus of hardware acceleration. The built-in awt graphics package is designed for portability on any system, with or without acceleration.

Back when I learned Java (it was 1.1 back then) the graphics performance was so horrible you couldn't do anything useful with it. Yes it could run on many devices and platforms, but usually the results were so horrible you weren't going to use it for anything but web applets. Phone programmers used the MIDP LCDUI libraries for anything that required image processing. Not that you could do much on a 66MHz phone with 240x400 or similar size screen. When you have less than 100,000 pixels there isn't much to draw. :-)

At any rate, games written in Java have nearly always relied on hardware-accelerated libraries rather than the general purpose drawing commands.

As for being at the mercy of the operating system, that is always true. The operating system, the drivers, and other running programs all can make a difference.

It might use hardware acceleration, or it might not, The problem is that the decision often seems random and it can change mid-execution, and you have no way to detect or control the situation. Sometimes you get lucky, sometimes you get unlucky, and it is extremely difficult for the program to know until it is too late.

Wow so even using JOGL can produce randomness in the methods?

I never knew I was at the hands of the system for using all parts of Java. I thought that only happens when I needed to use Java's paintComponent method.

So I am still at the mercy of the operating system even though I am doing my own painting. Things just got even more interesting.

Sorry for being unclear on that.

The "it" in the quotation was referring to Java draw calls. When you use Java's drawing system everything is handled by the Java implementation. They have a history of erratic performance. There is no way for the program to force the implementation to do anything. The erratic and sometimes painfully slow performance of the built in drawing libraries is one of many reasons that games will usually use a library that is written with performance in mind. As mentioned in the link, sometimes just resizing a window or moving it between monitors on a multi-monitor system can cause the built in functions like drawImage to dramatically change behavior.

When you use a library like JOGL, you are relying on the behavior of the library instead of the behavior of the Java implementation. The key difference is that JOGL and similar libraries have a focus of hardware acceleration. The built-in awt graphics package is designed for portability on any system, with or without acceleration.

Back when I learned Java (it was 1.1 back then) the graphics performance was so horrible you couldn't do anything useful with it. Yes it could run on many devices and platforms, but usually the results were so horrible you weren't going to use it for anything but web applets. Phone programmers used the MIDP LCDUI libraries for anything that required image processing. Not that you could do much on a 66MHz phone with 240x400 or similar size screen. When you have less than 100,000 pixels there isn't much to draw. :-)

At any rate, games written in Java have nearly always relied on hardware-accelerated libraries rather than the general purpose drawing commands.


As for being at the mercy of the operating system, that is always true. The operating system, the drivers, and other running programs all can make a difference.

Wow thanks for information! JOGL would be a great learning experience too!