Best type of image

[marcuiulian13]

Hello there!

I'm here again to ask next thing: As the title says, what is the best type of image (BufferedImage, Image, etc.) to render on a screen with BufferStrategy? With best i mean the one that is most fast. 

Thanks! 1.

[Geemili]

Buffer strategy just means that you don't draw directly to screen, you draw to an image that is drawn to screen so that you don't have flickering. You can just use the regular image. Buffered image is an image that the program can edit, instead of just loading it from a file.

[ra4king]

Image is an abstract class, you can't instantiate a copy of it. As far as I know, there are only 2 types of images: BufferedImage and VolatileImage. These days with the complex inner stuff Java2D does, there is no point bothering with VolatileImage. However, since as Geemili said BufferStrategy handles double buffering for you, it's best to directly draw on the Graphics2D object you get from BufferStrategy.getDrawGraphics();

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

[marcuiulian13]

Oh, this means that i am on the right path. What about BufferedImage type? Is ok to use any type or a specific type?

[ra4king]

Yes BufferedImages are the best to use. When loading images from file, you will also get BufferedImages using ImageIO.

[Vladiedoo]

I hope this isn't off topic (it seems related) but is there a list somewhere of the files that Java supports and which are preferred? For example to my knowledge Java wants to use .wav format for sound. I currently use .png for pictures, is that perhaps not efficient with Java?

[ra4king]

Java supports GIF, PNG, JPG, BMP, and WBMP image files. PNGs are best because they are lossless and support transparency.

Java Sound supports WAV, AIFF, and AU

[sproingie]

Images are loaded into bitmaps, they're all the same format internally, so whatever image format works best for you is going to be as fast to draw as any other.  PNG is probably the best format given that it's lossless and still supports decent compression.

Sound's a bit of a different story, but outside of third party sound libraries, you don't get much real choice anyway, so again it's largely down to whatever works, usually what has the best quality for the size.  A .wav (assuming you mean 44.1 stereo PCM) is certainly not compact, but you can be assured it's going to play on just about anything.  For lossy formats, ogg vorbis seems to be pretty popular these days (again, it'll need a third party lib like JOrbis)

[Vladiedoo]

  The information is appreciated, thanks!!!

[nsigma]

Neither of these points are really aimed at the OP!  Just me nitpicking. 

These days with the complex inner stuff Java2D does, there is no point bothering with VolatileImage.

A bit like saying there's no point in bothering with an FBO in OpenGL.  If you need an image that can be an accelerated rendering target then a VolatileImage is still the way to go.

Images are loaded into bitmaps, they're all the same format internally, so whatever image format works best for you is going to be as fast to draw as any other.

The format of BufferedImages loaded from files can be different, and if they don't become managed or you're doing an operation that won't be accelerated, are not going to draw at the same speed.

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

[ra4king]

BufferedImages are also managed, meaning their performance is similar to VolagileImage.

[nsigma]

BufferedImages are also managed, meaning their performance is similar to VolagileImage.

Did you read what I wrote???  I even italicized it!!! 

[ra4king]

So what exactly is a render target.

[BoBear2681]

I think he's referring to the fact that writing to a BufferedImage marks it as "dirty" so it can no longer be accelerated.

[nsigma]

So what exactly is a render target.

Reading from a BufferedImage can be accelerated when they're managed.  However, writing to them (ie. using their Graphics2D) uses software rendering.  Drawing on a VolatileImage can be accelerated in the same way that drawing to the BufferStrategy graphics can (AFAIK BufferStrategy uses a VolatileImage behind the scenes anyway), hence my parallel with FBOs.  Whether the drawing is actually accelerated depends on the operation, the pipeline, whether there's an r in the month, which way the wind's blowing, whether there's a blue moon ... well, you get my drift.

I think he's referring to the fact that writing to a BufferedImage marks it as "dirty" so it can no longer be accelerated.

No, I'm not.  If a BufferedImage is marked dirty by you rendering to it, as opposed to you grabbing the databuffer (or array in JDK7), then at some point in the future it will be re-accelerated.  This used to happen on the second draw - presume that's still the case.  The actual rendering to the BufferedImage will always be unaccelerated though.

[Z-Man]

... (AFAIK BufferStrategy uses a VolatileImage behind the scenes anyway) ...

BufferStrategy is just an abstract class so whether or not it uses VolatileImages is implementation dependent. However, as far as I can tell Component's implementation of createBufferStrategy() creates buffers that use VolatileImages. Unless of course you use a single buffer strategy, in which case it renders directly to the component.

Reading from a BufferedImage can be accelerated when they're managed.  However, writing to them (ie. using their Graphics2D) uses software rendering.  Drawing on a VolatileImage can be accelerated in the same way that drawing to the BufferStrategy graphics can

Then using a BufferedImage to load a sprite and draw that sprite to the screen is fine as long as your not planning to edit the image frequently BufferedImage will work just fine.

[nsigma]

Reading from a BufferedImage can be accelerated when they're managed.  However, writing to them (ie. using their Graphics2D) uses software rendering.  Drawing on a VolatileImage can be accelerated in the same way that drawing to the BufferStrategy graphics can

Then using a BufferedImage to load a sprite and draw that sprite to the screen is fine as long as your not planning to edit the image frequently BufferedImage will work just fine.

Yes, of course - that's what they're for!  I'm not arguing against that, just @ra4king's assertion that there is no point bothering with VolatileImage at all.  There are valid use cases for VolatileImage too.

[ra4king]

And what use cases would make VolatileImages better than BufferedImages?

[nsigma]

And what use cases would make VolatileImages better than BufferedImages?

I have a general feeling of going around in circles!   

If you need an off-screen image that has a chance of being drawn into using the accelerated pipeline. eg. if you had a complex sprite that was animating every frame, and you were drawing multiple copies to the screen, then you might consider drawing into a VolatileImage.  All drawing to a BufferedImage happens in software, so will be a bit / lot slower depending on the pipeline.

Using a VolatileImage is similar to using an FBO to render to a texture.  In fact, if you use the OpenGL pipeline (and hope) your VolatileImage should be backed by an FBO.

[65K]

With Java2D, I did all image blitting with volatile images exclusively, and it was pretty fast.