That's a good point, and it's an approach that I often recommend because of the nice heap savings, as long as you're willing to live with increased code complexity as Jim suggests. However, it's worth mentioning some subtle differences between our (current) implementations of managed images and VolatileImages that may make Jim's suggested approach problematic for some developers...
In the OGL pipeline (for JDK 6 and 7), a managed image is backed by an OpenGL texture, whereas a VolatileImage is backed by a pbuffer or FBO. OpenGL textures and FBOs can always be created with an alpha channel, but the same is not always true for pbuffers. So on older boards that do not support the FBO extension, you may find that translucent VolatileImages cannot be stored in VRAM. OpenGL textures and FBOs (regardless of opacity) can be transformed and blended with very high performance, but pbuffers can be very slow when drawn with a non-translate transformation or blended (with non-1.0f extra alpha). So on older boards that do not support the FBO extension, you may find that VolatileImages may be slow to transform or blend. The OpenGL textures that we create to back a managed image only use 3 or 4 bytes per pixel of VRAM, but when we create VolatileImages, the underlying pbuffer or FBO needs a depth buffer for shape clipping purposes, so this means 6-12 bytes per pixel of VRAM, which can really add up on older hardware where VRAM is limited. So if you create lots and lots of managed images, half the total memory will be spent in the Java heap, and half will be spent in VRAM. With VolatileImages, you may be using more VRAM than if you had used managed images, but you'll use less heap. Then again, you may end up exhausting VRAM more easily, in which case we may need to place future VolatileImages in the Java heap, which will be slower to render. As you can see, there are some very subtle trade-offs here that don't matter for most applications, but can be important for control freaks, which is why I divulged this information above. Just be aware that it reflects the current state of things, and only for the OGL pipeline (the forthcoming D3D9 pipeline has similar behavior), but it is all subject to change. For example, for a long time I've wanted to add smarts to our surface management code to benefit developers that use VolatileImages as Jim describes below. Specifically, if the contents of a VolatileImage are non-changing, we could promote it to an OpenGL texture, which would use less VRAM and might render faster, especially on systems where the FBO extension is not present. Again, we don't do this now, but it would be nice if we did someday. Thanks, Chris On May 22, 2007, at 3:24 PM, Jim Graham wrote:
It would be nice to get a method in Image that allows me to 'make this Image object managed if possible' without this workaround.If you want more explicit control over acceleration then the best route would be to create your own VolatileImage objects and manage them yourself. That is essentially what we are doing with the managed images, except for two differences: - you are subject to our acceleration heuristics (which we can probably make more convenient with a well-considered RFE) - the original image object remains in the heap wasting memory if you only ever want the accelerated versions In particular, if you are managing a bunch of sprites, then having a load routine which gets the image from ImageIO, immediately creates, validates, and copies the loaded image into a VolatileImage, and then drops the reference to the original loaded sprite - that will save a lot of Java heap memory by not having duplicate copies laying around. The price for that efficiency and control, though, is that you will need to track when the images get unloaded... ...jim ====================================================================== ===== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
