|
The BufferedImage objects definitely won't be accelerated due to your use of DataBuffer. You might think about using BufferedImage or WritableRaster API calls to set the pixel values, but depending on how much pixel-setting you're doing the pixel-sets may end up being more important to accelerate than the managed image copies. Copying the images to the back buffer won't cause the back buffer to punt unless the images are translucent (RGBA or whatever); that would cause us to lock the back buffer for read-modify-write, even if the source pixels actually don't have any translucency. So use opaque images if you can. You may also be hitting the bottleneck of simply copying these images down to the back buffer. That is, maybe your bottleneck isn't in getting Swing to update the screen, but in getting your unaccelerated images to copy to the back buffer. 10 times a seonc isn't a lot for one image, but how many images are they? How large are the images? it could be a lot of pixels we're pushing down the bus every second... I don't know if the lines would be causing a problem or not. I have seen situations where context-switching between the different rendering libraries we use (direct3d, ddraw, GDI) can affect performance. But I don't know if that would be the case here (especially with the modern video card/driver you have). You could try disabling d3d to see if that affects things: -Dsun.java2d.d3d=false Chet. Brian Peterson wrote: =========================================================================== 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".Good info -- thanks. A repaint is called on these dominate subpanels about 10 times a second.The application uses drawImage a lot. Most of the windows are panels that simply drawImage from an intermediate BufferedImage in its paintComponent. I doubt that these intermediate images are accelerated because I end up getting the DataBuffer to directly draw individual pixels. There's another subpanel that ends up drawing about 500 lines every repaint (10/sec). Would either of these trigger the punting you describe? I don't do any anti-aliased text. Or at least I don't think I do -- I always use the graphics hint to not anti-alias text. I'll try the parameter and see what happens. Thanks, Brian-----Original Message----- From: Chet Haase [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 21, 2004 7:34 PM To: Peterson, Brian Cc: [EMAIL PROTECTED] Subject: Re: [JAVA2D] lot of time in blitSurfaceData Ah, that's better. From this configuration, it seems like: - Swing _would_ have an accelerated back buffer (they started using VolatileImage in 1.4.0, and that should be (very) accelerated on your system. - Some other image types would also be accelerated (VolatileImage, and managed images created through specific APIs like Component.createImage(w, h) and GraphicsConfiguration.createCompatibleImage(w, h)). The only causes of huge amounts of time in Swing buffer copying that occur to me right off are: - Maybe the Swing buffer is getting punted: if you are doing lots of read or read-modify-write operations to the back buffer, then we may choose to punt it into system memory. Note that this will also happen if you are simply doing translucent operations (like translucent image copies) to the buffer, or _lots_ of anti-aliased text ops. For kicks, try running with -Dsun.java2d.ddforcevram=true to see if forcing the back buffer to stay in VRAM changes the characteristics at all. (Note that there's a good reason for us to punt; if you _are_ doing lots of read-modify-write ops to that buffer, those will probably kill your performance way before copying that buffer from system memory to the screen will). - Maybe the bottlenecks you are seeing are actually coming from some other operation in your app (not the Swing back buffer copies). Without knowing anyting about your app, it's pretty tough to tell... - Maybe you're forcing repainting so often that no matter how accelerated these copies are you're still spending most of the time updating the screen. Hope that helps... Chet. [EMAIL PROTECTED] wrote: |
- [JAVA2D] lot of time in blitSurfaceData Brian Peterson
- Re: [JAVA2D] lot of time in blitSurfaceData Chet Haase
- Re: [JAVA2D] lot of time in blitSurfaceData Brian Peterson
- Re: [JAVA2D] lot of time in blitSurfaceData Chet Haase
- Re: [JAVA2D] lot of time in blitSurfaceData Brian Peterson
- Chet Haase
