I am attempting to use the Managed Images API by calling GraphicsConfiguration.createCompatibleImage(). It is my understanding that these images may be accelerated by the underlying framework by placing them in VRAM.
I have constructed a test program which successfully uses this optimization, and it is quite fast. However, for my ultimate application, I have a tiled image that I would like to display as rapidly as possible. My plan was to copy the contents of individual tiles into images created using the GraphicsConfiguration.createCompatibleImage() call. Then I would cache the results of these calls so that I can redraw the image rapidly if the tiles have not changed. This is very useful for redrawing a large image background rapidly when displaying animated graphics on top of the image. It is also useful for scrolling across an image, when redisplaying large portions of the image unchanged. Unfortunately, because the accelerated images are managed under the covers by the JVM, it is necessarily difficult to control such behavior in my own application. If we are caching these images, we will want to trigger them to be removed from VRAM when they are dumped from the cache. My major question is: does the flush() method on java.awt.Image cause any accelerated data in the VRAM to be flushed as well? This is a very exciting and promising enhancement and I am hoping that more information will come out about how to use it properly. Mike Nidel =========================================================================== 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".
