Err.. while you are clearing things up maybe you can straighten me out...
I thought that Managed Images essentially used Volatile Images, or an equivalent internal representation for the "managed" accelerated image data. From what you wrote above it would seem that this is not the case. So now I'm wondering, why isn't it the case? It would seem to make sense from a debugging, code-reuse, etc. point of view that a Managed Image should basically just be a way to get a Volatile Image when you didn't specifically ask for one. I.e. the volatile image is "managed" for you, so you don't have to worry about restoring a lost accelerated surface.
I assume I am somehow oversimplifying the problem. But I would appreciate it if you could toss a few clues my way so I have an appreciation for what a Managed Image really means.
Conceptually, it works pretty much like you mention. But this is another area where misinformation has been spread by certain people on this board... Basically they say a "managed image" uses VolatileImages internally, but that's simply not true.
Inside all kinds of Images (since JDK 5) we have something called a SurfaceManager. So BufferedImages have a CachingSurfaceManager, and VolatileImages have a VolatileSurfaceManager. In the end, both SM's manage surfaces that may or may not be "volatile", but the strategies they use for managing those surfaces are slightly different. When I say "surface", I mean a heap-based buffer, or an OpenGL texture, or an OpenGL pbuffer, or a DDraw surface, or a D3D texture, or an X11 Pixmap, or something else. If you really want the full story, download the Mustang sources and poke around src/share/classes/sun/awt/image/*SurfaceManager.java... I could go on, but frankly it's my birthday, and I don't even know why I'm working at all today
This blog may help a bit too:http://weblogs.java.net/blog/chet/archive/2003/08/bufferedimage_a_1.html