Damon,
> One reason I'd prefer VolatileImages over BufferedImages is that it allows the > application to manage the video card memory as a cache. > > As one example: Keep track of all the VI's we've created and when last used. If > we try to create a new one and getCapabilities().isAccelerated() == false then > we can flsuh() some old ones, and re-create the new one accelerated. If a > flushed one is asked for again, re-create it. > > This control is not possible with BufferedImages. I know this is implementation > detail but.... could someone describe how BufferedImages being loaded into and > out of VRAM currently works? Is it something similar to what I described above. Unfortunately it is not that sophisticated. VRAM is currently managed as a pool for both Volatile and non-Volatile images and is allocated on a first-come, first-served basis. Volatile images can control their use of this resource (via the flush() call), but hidden-acceleration images (those that we try to cache and accelerate under-the-hood) will sipmly grab the memory if it's there and if it looks like acceleration is worthwhile. For example, a non-Vol buffer that is being modified every frame will probably never allocate VRAM because we never see the advantage from copying down the changes to the cached version. A static sprite, on the other hand, will grab some VRAM almost immediately and will continue to use it until the image is GC'd. > > What are the conditions that cause a BufferedImage to go into VRAM. Is there > anyway to hint to a BufferedImages to be put into VRAM. Like graphics.dispose() > or seomthing? See above explanation... > > The reason I'm asking is because the application I'm developing will rely > heavily on caching of accelerated images. The best recommendation I have for you now is to pre-allocate the stuff that you really want in VRAM, keeping in mind the first-come, first- served principal. Also, you should be able to manage vram for your own Volatile images even if there are also non-Volatile images taking up the same resource. As an example, let's say someone just resized your window and you need to create a new back buffer. You obviously don't need the old back buffer any more and you want to use that VRAM for your new back buffer. The best thing to do (and this is what's done inside of Swing) is to first flush the old back buffer and then allocate the new one. Assuming there are no other threads in your app allocating image memory at the same time, this should guarantee that the VRAM from the old buffer is available for reuse immediately by the new buffer. >>In the next release, when we will hopefully >>be able to support even more functionality in hardware (such as >>alpha compositing and more advanced drawing primitives), we will >>hopefully have more ways to create different kinds of accelerated >>images (both explicitly and implicitly). >> > > Sounds like what I want. By next release are you talking 1.4 (release), 1.4.1 or > 1.5? Certainly not 1.4 (we're freezing that in the next few days). Anything requiring API changes would have to be 1.5. Anything that could be done under-the-hood (such as VRAM management or acceleration for certain existing image types) could be done between 1.4 and 1.5, depending on the work required. > Thanks for the help and detailed response, Sure thing. Thanks for the input. It's great to see people actually starting to use the stuff we've been working on for a while; input from actual users is key to getting the API and the implementation right. Chet. =========================================================================== 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".
