 |
Chet Hasse writes:
Thanks for checking out the blog: It's so nice to get noticed!
Let me clarify a couple of things about VolatileImages and the issues that were raised on this forum.:
VolatileImage vs. managed images (aka "automatic images", but I prefer "managed images" because it's more accurate and informative):
There is almost no reason to use VolatileImages instead of managed images for most cases.
The only reasons to use a VolatileImage are:
- If you want rendering TO the image to be accelerated (managed images have their primary copy in system memory and thus all rendering operations TO that image happen through software routines)
- If you want to more actively manage the accelerated memory (eg, VRAM). It's a little easier to tell what's going on with a
VolatileImage (in terms of VRAM usage) than with a managed image. If all you want is a sprite that probably gets accelerated for its copies to the back buffer or screen, managed images are the way to go. No need to hassle with Volatiles.
VolatileImage vs. BufferStrategy buffers:
If you are using a BufferStrategy, then these are (sorta) managed for you; if one gets lost, then it will automatically be reinstated (we manage all of this with VolatileImages internally, and call validate when necessary). Note that you still have a contentsLost() method and situation to deal with, but in the case of a back buffer (which gets re-rendered every frame), that's not a big deal since you're just going to wipe it and re-render anyway.
VolatileImages and translucency:
a) The API: in 1.5, we will (finally) have the ability to create a translucent VolatileImage (currently, you can only get an opaque VImage).
b) contentsLost() and re-compositing VImages problems: I don't see a huge issue here. Image loss is not a common occurrence (unless your game wants to change the display mode every frame to freak out the users. I can see it now: "Seizure: A game of epileptic proprotions"). So the way to handle any image loss situation is just to re-render the entire frame. Sure, it costs you a frame's worth of rendering time; but when the display mode changes there are a lot more disturbing things happening on the screen than an momentary drop in your frame rate.
VolatileImage and automatic revalidation:
The whole reason that we force you to manage these images is that we cannot restore the contents for you. If we were to keep the primary copy in memory and do an automatic restore (hmmm - sounds like a managed image to me...), then by definition, we would have to do all of the rendering to that primary surface first (since we can lose the VRAM version at any time). This means that all of that fine rendering would happen through our software loops and you'd lose the benefits of hw acceleration on your rendering-to ops. "But I don't care about the render-to speed; I only render to my sprites once and then just care about the copy-from speed" - See my point above about managed images; you shouldn't have to use a VolatileImage in this case.
Hopefully this clears things up a bit. In any case, please check out the follow-on blog, which is basically a series of Q&As on common VolatileImage issues (including some of the points raised here; in fact, I might borrow some of these ideas for more Qs).
And feel free to post replies to the blogs; I think the discussions after the blogs can be even more informative than the original article (check out the ones on BufferedImage on that site; there's some good stuff in the feedback sections).
Chet.
If you need more Informations about Volatile Images, look here:
ftp://ftp.java.sun.com/docs/j2se1.4/VolatileImage.pdf
-- ScottWPalmer - 12 Sep 2003
|