Re: [JAVA2D] High performance graphics on java.sun.com
Just to let everyone know I've downloaded and installed JDK 1.4 beta 3 and the performance issues I posted about below have all disappeared. Yay! But, unfortunately, a bug has appeared in beta 3 that screws up my test framework. Damon. Damon Maria wrote: http://java.sun.com/products/java-media/2D/perf_graphics.html Hi all, having read thru the above document I'm currently writing a test of JDK 1.4's Java2D performance for a project. I know it's in beta still but... In the section Tips for Attaining Better Performance it talks about acceleration of images with 1-bit transparency (which I assume is Transparency.BITMASK). To quote: Acceleration support for 1-bit transparency enables you to accelerate sprites with transparent pixels so... However when I gc.createCompatibleImage( width, height, Transparency.BITMASK ) the resulting drawImage()'s are really slow. My test (filling the screen with 10x10 of these images) for different transparencies passed into createCompatibleImage() results in: OPAQUE 25 fps BITMASK 1 fps TRANSLUCENT 12 fps fps = frames/second - higher = better Strange, I would have thought BITMASK would have been close to OPAQUE because it would be accelerated by DirectDraw, and TRANSLUCENT would be the slowest. Can someone explain why BITMASK isn't accelerated as the document says it should be. Also, how do I create a VolatileImage with 1-bit transparency? I can't seem to find anyway to do it? There is no createVolatileImage( width, hieght, transparency ). And incidentally, using a VolatileImage in the above test results in 50 fps. My system: Windows 2K, DirectDraw 8, Riva TNT 2, JDK 1.4 beta 2. thanks in advance, Damon. === 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.
Re: [JAVA2D] High performance graphics on java.sun.com
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.
Re: [JAVA2D] High performance graphics on java.sun.com
Hi Damon, Have you tried your application on 1.4 beta 3 yet? I believe that beta2 was missing support for the 25-bit format we use for transparent images in most Graphics Configurations. That should help with your transparent performance numbers quite a lot. 1.4 beta 3 also has much better support for scaling Volatile and transparently accelerated offscreen and toolkit images... ...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.
Re: [JAVA2D] High performance graphics on java.sun.com
Chet Haase wrote: There is a flag to force hardware acceleration through ddraw if that is what you are trying to do (-Dsun.java2d.ddscale=true)). This flag doesn't change my results. I'm not currently scaling anyway. But will be testing that soon. If you could send me more information about your testing situation (especially your test app), I can take a look at what's causing the problem. Will do, but off this list. On your second question, there is currently no way to create a VolatileImage with transparency. This simply did not make this first cut at our accelerated image API. Although this would be useful functionality, we were trying to be pretty spare at this point and get the common cases right first (like creating a back buffer in hardware). 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. 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? The reason I'm asking is because the application I'm developing will rely heavily on caching of accelerated images. 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? Thanks for the help and detailed response, Damon. === 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.
