Bottleneck Drawing Large Image

[Tetragrammaton]

I'm a Java game newbie, and I've got a bottleneck that I just can't understand. I've got an otherwise-finished game that's got unacceptable performance, and I've finally figured out the source of the problem.

I'm working with an 800x600 frame. When I draw a single 800x600 image over the whole thing (my background image), I get 20 FPS. But, if I take a 200x200 image and draw it 12 times in a grid, I get 50-100 FPS. It seems to me that there's the same amount of image data getting pushed to the buffer; why, then, does this screw up so badly?

I haven't tested this particular issue on Windows, but the slow version of my game runs even slower on there than on my Linux machine.

Examples of both the single image and the grid can be found here: http://forum.java.sun.com/thread.jspa?threadID=5299987

[oNyx]

Use a maximum size of 2^16 (65536) pixels. E.g. 256x256.

[Tetragrammaton]

Do I have to tile then? Is scaling safe?

Games published by our own members! Check 'em out!

[oNyx]

Tile it. Scaling isn't that fast.

If you're using several background images it might be a good idea to create some kind of Background class, which splits the background image into tiles (once - in the constructor) and draws all of the tiles in a draw() or render() method.

[Tetragrammaton]

Thanks for the help.

Honestly, I'm surprised that this doesn't seem to be an especially common issue. I'd expect "background drawing" to be so standard a task that Sun would provide a method to take care of it for us.

EDIT: Actually, this didn't give the expected performance boost. Tiling with separate 200x200 images just made it slower (as did tiling the same image, oddly enough). Commenting out these drawImage calls and replacing them with a fillRect to clear the image sends the FPS skyrocketing, still.

Any other ideas, or experiments to try?

[Wildern]

Any chance there is transparency in your image (ie: .png) ?

[Tetragrammaton]

There's no alpha channel in the .png and the BufferedImage type is RGB.

I really don't get this. The example I linked to in the first post shows the exact same sort of tiling, and it's fast. What's changed?

[trembovetski]

What is your OS, Java version, video board?

Dmitri

[Tetragrammaton]

Ubuntu Hardy Heron
Java 1.6
Some low-grade Quadro

[trembovetski]

Thanks for the data.

Could you please run your app with -Dsun.java2d.trace=count (let it run for a few seconds, then quit), with tiling and w/o it and post the output?

Dmitri

Games published by our own members! Check 'em out!

[CaptainJester]

Check to make sure that your images are in the same format as your screen.  Otherwise you will lose performance as well.  To check this easily, follow these steps.

1.  Load your images.
2.  Create images that are compatable with the screen using GraphicsConfiguration.createCompatibleImage(int width,
 int height)
3. Copy your loaded images to the screen compatable ones created in step 2.
4. Use the screen compatable images created in step 2 to draw your images.

[Tetragrammaton]

Thanks for the data.

Could you please run your app with -Dsun.java2d.trace=count (let it run for a few seconds, then quit), with tiling and w/o it and post the output?

Dmitri

Of course. My game loads to a menu screen. On both runs I tried to rapidly get into the main game rendering section (with the background or tiles) and then let it run for several more seconds.

First, with the single large background graphic:

1   2   3   4   5   6   7   8   9   10   11   12   13   14

354 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb) 17543 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntRgb) 354 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcOverNoEa, IntArgb) 2 calls to sun.java2d.x11.X11PMBlitLoops::Blit("Integer RGB Pixmap", SrcNoEa, "Integer RGB Pixmap") 65905 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntRgb) 354 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcOverNoEa, IntArgb) 184 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb) 57398 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcOverNoEa, IntRgb) 57398 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcOverNoEa, IntRgb) 6 calls to X11FillRect 58673 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb) 8507 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntRgb) 921 calls to sun.java2d.loops.TransformHelper::TransformHelper(IntArgb, SrcNoEa, IntArgbPre) 267599 total calls to 13 different primitives

Second, tiling a single 200x200 image 12 times:

1   2   3   4   5   6   7   8   9   10   11   12   13

40429 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntRgb) 34754 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcOverNoEa, IntRgb) 135 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, SrcOver, IntArgb) 5675 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgb, SrcOverNoEa, IntRgb) 34754 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcOverNoEa, IntRgb) 2 calls to sun.java2d.x11.X11PMBlitLoops::Blit("Integer RGB Pixmap", SrcNoEa, "Integer RGB Pixmap") 135 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(Any, SrcOverNoEa, IntArgb) 35960 calls to sun.java2d.loops.OpaqueCopyAnyToArgb::Blit(Any, SrcNoEa, IntArgb) 6 calls to X11FillRect 1071 calls to sun.java2d.loops.TransformHelper::TransformHelper(IntArgb, SrcNoEa, IntArgbPre) 173 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb) 11638 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntRgb) 135 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(Any, SrcOverNoEa, IntArgb)

[Tetragrammaton]

Problem fixed!

It turns out that these images weren't accelerated because they were directly created from ImageIO.read. Images created with a BufferedImage constructor are managed images, but those taken directly from ImageIO.read are not.

By using a BufferedImage constructor and then using graphics.drawImage(ImageIO.read(---)), I was able to get my performance back to where it should be.

Thanks for everyone's help!

[trembovetski]

I believe the issue with some images read with ImageII not being accelerated
were resolved in 6u10 (I don't remember if they were forward ported to Java7
or openjdk6).

Dmitri

[trembovetski]

I believe the issue with some images read with ImageIO not being accelerated
were resolved in 6u10 (I don't remember if they were forward ported to Java7
or openjdk6).

Dmitri