This is what i wrote for handle volatile images like explained here: http://gpwiki.org/index.php/Java:Tutorials:VolatileImageTo test this VImage class i made a program that has 2 balls which can controllable form keyboard and added a 1920x1200 background image.It worked well with volatile images on window mode but when i toggle full screen mode fps dropped down immediately from 60 to 40 and sometimes i got heap space exception.After set useVolatileImages as false fps increased again and working perfect.Now i'm wondering am i doing something wrong?

This is what i wrote for handle volatile images like explained here: http://gpwiki.org/index.php/Java:Tutorials:VolatileImageTo test this VImage class i made a program that has 2 balls which can controllable form keyboard and added a 1920x1200 background image.It worked well with volatile images on window mode but when i toggle full screen mode fps dropped down immediately from 60 to 40 and sometimes i got heap space exception.After set useVolatileImages as false fps increased again and working perfect.Now i'm wondering am i doing something wrong?

I don't know who wrote that Tutorial, but it's potencially broken.

The Copying from a VolatileImage example does not account for the potencial of the VolatileImage becoming invalidated in the time-frame between the image being recreated & the image being drawn onto it's destination.

To work around this limitation the drawImage itself has to be part of a loop; with the validity check *after* the drawImage. This ensures the VolatileImage is drawn atleast once while in a valid state.

However this exposes a more fundamental flaw in the entire VolatileImage API when dealing with translucent VolatileImages or when using VolatileImages in conjunction with more exotic Compositing rules.

The above suggested draw loop ensures the VolatileImage is drawn to the destination successfully atleast once; and this is fine if you are simply replacing the pixel components of the destination.However if you are performing a composition (either an AlphaComposite or some kind of custom colour composite) you will run into trouble because there is no way to guarantee that the VolatileImage was drawn just once.

I've played with VolatileImages a lot lately and find that they don't work in Applets, but do in JFrames.

Also, they are not meant to be necessary since a BufferedImage is meant to use a backing VolatileImage for hardware-acceleration and take care of the 'volatility' of the surface for you automatically, but in my tests VolatileImages run faster than BufferedImages by about 30 - 40%.Try running this demo and press 'I' to toggle between BufferedImages and VolatileImages and see the change in FPS.http://www.keithwoodward.com/straightedge/straightedge.jnlp

Interesting, thanks for letting me know. There must be something funny going on in the pipeline. Some computers do, some don't.

I remember that Dmitri Trembovetski, who works on Java2D at oracle/sun, said that BufferedImages were not meant to be inferior to VolatileImages because under the hood BI's are backed by VI's, but on my computer and others it's not the case.

PS: make sure you clicked inside the applet and/or jframe when you press I or it won't do anything.

I've played with VolatileImages a lot lately and find that they don't work in Applets, but do in JFrames.

Also, they are not meant to be necessary since a BufferedImage is meant to use a backing VolatileImage for hardware-acceleration and take care of the 'volatility' of the surface for you automatically, but in my tests VolatileImages run faster than BufferedImages by about 30 - 40%.Try running this demo and press 'I' to toggle between BufferedImages and VolatileImages and see the change in FPS.http://www.keithwoodward.com/straightedge/straightedge.jnlp

The various hardware acceleration and video ram optimizations behind the scenes in Java2D have always been flakey at best. Recently where I worked we experimented with turning on the OpenGL pipeline by default for something we work on, and it became unstable on certain OS's.

IMHO if you really want hardware acceleration then use Slick, JOGL, LWJGL, WebGL powered by GWT or an applet, or something else.

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