Hi!It's been a while since Sun announced graphics acceleration input for their Java platform. It's "true", graphics are used as data buffers rendered to the graphics card output throughout various call-backs, such as RenderedImage's or VolatileImage's. Indeed OpenGL buffers provided the most of soft- and hard-ware acceleration for high-end graphics.BUT the problem arises when the native librairies don't load on all system's or have to be disabled (e.g. the JAI codecsLib is disabled for Windows) or the System graphics layer are system-dependent (e.g. Apple's Quartz or M'soft DirectX or the open library OpenGL). Sun Java dev's released their Java 6th edition to provide more compatibility with the recent graphics cards buffers and routines, which has still some enhancements to be made till 7th edition. One of the more accessible solution is to convert RenderedImage to VolatileImage instances to enter up into the VRAM buffers. Heading to this way, we face an uneasy situation where the VolatileImage is known to be instanciated OPAQUE. Now how to provide the same TRANSPARENCY and easiness of the RenderedImage's ?? The solution has become real (since 5th edition )with the VolatileImage TRANSLUCENT parameter. Well, this is not sufficient, the background of VolatileImage is still filled with some WHITE-COLOR that renders opaque. So here's the way to render ALL YOUR VOLATILE IMAGES W/ FULL TRANSPARENCY AS BACKGROUND :

As you can see, the VolatileImage is given the TRANSLUCENT parameter and then Graphics are realized once to fill them with the AlphaComposite DST_IN and the alpha value to a floating zero. THIS CHANGES A LOT THE RENDERING SPEED.

EDIT : it should be reset back to the default Composite, which must be opaque SRC_OVER.

I wonder why you don't simply use BufferedImages for your sprites, if they are read-only?This is what BufferedImages have been designed for (since 1.5), e.g. I know about my old GeForce488Go which has quite a high per-primitive overhead for each rendered VI, whereas thousands of BIs are no problem at all. (I guess the pbuffer state changes are killing it)

indeed BufferedImage's are the most compatible. They are also known as RenderedImage in a 2D context. But they're not as fast as VolatileImage instances because each render cycle has to fetch pixels data from a RAM allocated buffer, unlike Volatile buffer which are known to solely use the VRAM allocation. That is like looking data into the harddisk compared to fetching "living" data into the RAM memory; i.e. your Graphics Card CPU would look directly into its VRAM buffer in a Volatile context where he could find valid Image's.further benchmarking are made with the BufferStrategy "pBuffer" and the usual JFC double-buffering, The "full-screen exclusive" mode can create 2+ Volatile buffers that are flipped or swapped as the render cycle processes graphics contents which is much faster.

But they're not as fast as VolatileImage instances because each render cycle has to fetch pixels data from a RAM allocated buffer, unlike Volatile buffer which are known to solely use the VRAM allocation.

Sorry but thats not true. BufferedImages are, if accalerated, copied to VRAM and when blitted to another GPU resource the vram-copy is used.

Sorry but I know what I am talking about. If you're not modyfing your VolatielImages your work is completly useless - BufferedImages provide excatly the same functionality without the risk of loosing their content.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org