Performance of large images with clipping vs. smaller images?

Java 2D
#1

Hello,

Is there a lot overhead when painting large images (e.g. 1500x1000, still small enough to get accalerated) with clipping enabled (e.g. 100x20) compared to painting small images (100x20)?
I am mostly interrested about the X11 pipeline :wink:

Thank you in advance, lg Clemens

#2

The NVidia driver on my other computer was - while using the OpenGL pipeline - MUCH happier about drawing parts of large images than it was about drawing very small images. I made a thread reporting some numbers IIRC. I could find it if you like.

EDIT: I might as well find that thread now. Which I did. Here it is:

http://www.java-gaming.org/forums/index.php?topic=10828.0

It’s probably related to numerous previous complaints about bad tile-rendering performance.

#3

You’d love to read this thread: http://www.java-gaming.org/forums/index.php?topic=13768.0. It was answered by Dmitri Trembovetski & contains a great benchmark program by Woogley that you could use to test your problem. 8)

The results of that thread were basically:
clipping is the worst
sub-imaging (where you have lots of little images) is the best for java 1.5 and before
graphics.drawImage(image, srcRect, destRect) is the fastest in Mustang with Direct3D, according to Trembovetski.

So use this method if you only want to draw rectangular parts of that big image:
Graphics.drawImage(Image img,
int dx1,
int dy1,
int dx2,
int dy2,
int sx1,
int sy1,
int sx2,
int sy2,
ImageObserver observer)

Keith

#4

yeah that maybe true but that is the test for comparing ways to draw parts of an image, not the whole image also as Linuxhippy needs. Personally I don’t see why would painting large image by parts would be faster thatn painting it all at once, can anybody explain?

#5

Thanks a lot, it explained it far better and detailed than I ever hoped for :slight_smile:

#6

My pleasure, I’m still grateful for your tips on the sun java forums back in the day… :slight_smile:

#7

Kova, the reason why it might sometimes be faster to slice an image into smaller images, is that very large images will never be available in vram (too large). Slicing the large image into smaller images allows for them to be available in vram, if not the entire collection of smaller images, - at least some of them. If you have a 128mb card, “testing” by loading one big image really doesnt cut it. In a real setting, you will have lots of more images you’d like in vram, (in addition to what is in there from other processes and applications, etc), and then there just might not be place for your wickedly cool but also wickedly huge background image :wink: And of course, you can only fit so much onto a screen, so by slicing it (because you only need to draw portions of the large image at any given time), you’re making the total amount of kb less, and more likely to fit into your available vram.

#8

Yes I suppose that is correct but Linuxhippy said in his post it’s small enough to get accelareted:

[quote](e.g. 1500x1000, still small enough to get accalerated)
[/quote]
If it’s accelareted, dosen’t that mean it fits in vram?

#9

I can’t see why the total kb will be less, but the main reason why sub-images are faster than clipping a big image is that no clipping computation is needed. Anyway, sub-images are just as fast as having a big image & doing Graphics.drawImage(img, srcRect, destRect) in Java 1.5. And in Java 1.6 (Mustang) big images that you do the Graphics.drawImage(img, srcRect, destRect) with are apparently faster in Mustang compared with separate sub-images since Direct3D doesn’t need to do a ‘texture swap’ which is expensive, according to Dmitri T.

#10

Kova:

Most likely able to fit in vram, - but how can anyone guarantee that? :slight_smile: It depends on how much else is in there.

CommanderKeith:

You are right, the sum is no less KB. But with split images, you might have room to accellerate 80% of them, which beats 0% in a worst case scenario. :slight_smile:

#11

well if user is running more apps and/or games he shouldn’t be suprised if he sees the game slow (whole vram used, image dosen’t get accelarated) … but this is very unlikely to happen.
btw. is there a way to find out how many space is left in vram? Only if it’s at 90%+ of it’s capacity I would start using subimages… or even avoid whole thing becouse of unlikeliness of that happening. I don’t know much about it, but it sounds very unneccissary to implement such algorithams for very rare occasions they’ll be needed.

#12

It’s most definitely a matter of taste, indeed. I tend to use subimages for other reasons as well. ( More flexible backgrounds, adding craters to single tiles if something explodes above it, etc). An algorithm to draw (square) subimages isn’t really rocket science, - but like you said, depending on your game it might definitely not be necessary.