BufferedImage/Exclusive mode performance

[Monkey Magic]

Hi all,

I'm trying to write a simple 2d shooter in java. I've got full screen
exclusive mode working fine. The problem occurred when I decided I
wanted to rotate the screen under the ship.

Rather than rotate every image individually I decided to draw to a
BufferedImage rather than directly to the screen, cast the Graphics
object returned from BufferStrategy.getDrawGraphics() to a Graphics2D
and call rotate() on it so that when I call
g.drawImage(BufferedImage,0,0,..) the entire screen will have been
rotated.

I found that this was about 10 times slower than drawing directly on
the graphics object. At first I thought that it was the rotate slowing
things down but it is just as slow without the rotate. Is that what I
should expect? It just seems to be a very large performance decrease.
Am I approaching this in completely the wrong way? Should I get the
pixels for each image and perform the rotation myself?

When I tweaked my graphics card settings to tell applications not
to wait for the vertical sync I was getting 430-440 frames per second
which dropped to 40 - 60 when I started using the BufferedImage.

I'm using win2k and jdk 1.4.2_03-b02

Without the bufferedImage I did

Graphics g = bufferStrategy.getDrawGraphics();
for(blah to blah)
{
g.drawImage(image,,,);
}
if (!bufferStrategy.contentsLost())
{
bufferStrategy.show();
g.dispose();
}
----------------------------------
With the BufferedImage I had

BufferedImage buf = new BufferedImage(800,600,2);
Graphics g1 = buf.getGraphics();
Graphics g = bufferStrategy.getDrawGraphics();
for(blah to blah)
{
g1.drawImage(image,,,);
}
//g.rotate(...);
g.drawImage(buf,,,);
if (!bufferStrategy.contentsLost())
{
bufferStrategy.show();
g.dispose();
}

Any light you could shed would be greatly appreciated.
I posted this through google so won't see any responses
for a day or so or indeed at all if you have No-archive
set.

Thanks

 

[Boudewijn Dijkstra]

Rather than rotate every image individually I decided to draw to a
BufferedImage rather than directly to the screen, cast the Graphics
object returned from BufferStrategy.getDrawGraphics() to a Graphics2D
and call rotate() on it so that when I call
g.drawImage(BufferedImage,0,0,..) the entire screen will have been
rotated.

I found that this was about 10 times slower than drawing directly on
the graphics object. At first I thought that it was the rotate slowing
things down but it is just as slow without the rotate. Is that what I
should expect? It just seems to be a very large performance decrease.
Am I approaching this in completely the wrong way? Should I get the
pixels for each image and perform the rotation myself?

BufferedImage works slow, and there is nothing you can do about it. You
should use the newer VolatileImage, which is designed to be fast.

 

[Monkey Magic]

BufferedImage works slow, and there is nothing you can do about it. You
should use the newer VolatileImage, which is designed to be fast.

Ah. I haven't tried that. I'll give it a go. Thanks for the response.

 

[Monkey Magic]

BufferedImage works slow, and there is nothing you can do about it. You
should use the newer VolatileImage, which is designed to be fast.

I've tried this now and the volatileImage seems to be about 4-5 times
faster than the BufferedImage.

I initially had a problem with either the image not being accelerated or
the program stopping immediately after changing the screen resolution
but solved this elegantly ) by putting a sleep statement between
changing the resolution and declaring the volatile image.

I found this

http://java.sun.com/j2se/1.4/pdf/VolatileImage.pdf

on suns site. Which was nice.

Ta very much.

 

[Boudewijn Dijkstra]

I've tried this now and the volatileImage seems to be about 4-5 times
faster than the BufferedImage.

I initially had a problem with either the image not being accelerated or
the program stopping immediately after changing the screen resolution
but solved this elegantly ) by putting a sleep statement between
changing the resolution and declaring the volatile image.

Yes, the example code is a bit dangerous. Every one of those loops should
contain a sleep statement, it has to be only 1 ms. This is to give the
system a chance to recover from events like resolution changes.