Applet/frame low fps problem

Newbie & Debugging Questions
#1

Hi, I’m relatively new to Java, but can’t get my head round this.

I was creating a 2d game engine, but was noticing very low fps when the applet size was increased. I created an new applet that has size of 1200x800. The applet only fills a black rectangle, draws it onto a bufferedImage, then draws the bufferedimage, using the overriden ‘update()’ method. It gets approx 45-51 fps.

I then created a non-applet version extending JPanel. This does the same, and gets 47-80fps.

These fps ratings go down with larger screen size, but I want a large screensize. The codes are very short; can anyone tell me what I’m missing here? What have I completely missed out on? I refuse to believe this is the best fps I can acheive. Drawing layers from images at fullscreen I got down to 19fps. I also tried drawing several smaller boxes onto the screen at different points, same problem.

The applet version: http://pastie.org/1676959
JPanel: http://pastie.org/1676965

#2

Use Canvas to draw into for both applet and desktop. Then you can use BufferStrategy since that is faster than using BufferedImage because BufferStrategy uses page flipping (changing the memory pointer of the image) while BufferedImage uses page blitting (copying the image bit by bit).

Hope that helped ;D

#3

I am wondering about a few things:

  1. what is happening in the fpscounter code? (Side note: usually a Class starts with a capital letter.)
  2. maybe it would be faster to use setBackground and clearRect than to draw the black background?
	g2.setBackground(new Color(0,0,0)); 
	g2.clearRect(0,0,width,height);  //assumes you've set width, height to the desired size
  1. maybe since all the drawing is occuring within paintComponent anyway, simply draw directly onto the graphics object instead of drawing to your buffer and then copying from the buffer to the graphics object? This also avoids the blitting mentioned by ra4king.

Note that you can pass the update’s or paintComponent’s graphic object to draw methods that you create for anything that needs to be drawn. For example, consider that you can define a public method such as: fpscounter.draw(Graphics2D). Then, in your update/paintComponent code, make FPS.draw(g2) a statement. (Side note: usually an object name starts with a lowercase letter.)

I haven’t tried drawing directly on an Applet, myself. I’ve only used JApplet and drawn on a JPanel within that. It’s not necessarily the fastest way to do things, but Java is fast enough that even so I’ve gotten good fps rates.

#4

@Philfrei
There is nothing wrong with his code. He could not make it any more efficient (unless FPS.tick() is the problem, but I doubt it is).
First, in the JPanel example, you can directly draw into ‘g’ since JPanel is automatically double buffered so no need to use BufferedImage.
Second, there is technically nothing wrong with your code. However, there is a reason why there is paint(Graphics g) :stuck_out_tongue:

#5

Thanks for your help guys. I had no idea about this blitting, completely explains the larger resolution! I’m gong to re-construct it with the canvas and bufferstratergy, and all being well apply this to my project.

My tick() just increases a variable, checks to see if time between start and current time is > 1000ms then resets start time and the variable. Nothing fancy, whipped it up quickly to see what was going on.

#6

Also remember next time you want to use any Swing component to draw into, they are automatically double buffered.

For Canvas, you don’t even need your own extended Canvas class. You can just create a new Canvas object, add it to the JFrame, and use it’s BufferStrategy to draw.
http://ra4king.is-a-geek.net/javadocs/java/awt/Canvas.html
http://ra4king.is-a-geek.net/javadocs/java/awt/image/BufferStrategy.html

#7

@ ra4king – Well excuuuuse me! :wink:

If you set the background color in the constructor, setBackground(Color.black); for example, you avoid an unnecessary setPaint command, since you can use clearRect. That seems like a small but real efficiency.

Also, I’ve never seen a Java tutorial that cleared or initialized a graphics area via a fillRect. In the Java Tutorials Graphics2D section they always use clearRect. Do you know why? I don’t. Maybe there is no difference, but as I said in my suggestion, “maybe”!

I don’t understand why you say to ME “he can’t make it any more efficient” then suggest drawing directly into the graphic object (as I did). Doing so eliminates the creation of an unneeded BufferedImage and the elimination of an unneeded drawImage command. Yes? I can’t (and didn’t try to) say how significant this might be. I voiced them as suggestions as things to consider.

Pax

#8

clearRect and fillRect do the same thing except one uses the background color and the other uses the current set color, respectively.

Plus I meant the Applet one is fine. The JPanel example is the one that needs fixing ;D

#9

I fixed the JFrame as suggested, it runs awesomely. What sort of buffering is it using? It works even when I draw 3 different fullscreen sized images every frame.

#10

If I recall correctly, fillRect just paints over the specified rectangle with the color while clearRect replaces the pixels with the background color (try this with partly transparent colors)

#11

From the JavaDoc “Beginning with Java 1.1, the background color of offscreen images may be system dependent. Applications should use setColor followed by fillRect to ensure that an offscreen image is cleared to a specific color”.

You can setBackground from Graphics2D or for the underlining component to control this. I don’t know if there is any performance difference between the two operations.

#12

Just to note something, if you’re gonna use BufferStrategy, there is no need to clearRect or fillRect since the screen is automatically filled with the background color.