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:
Sorry for the sparse description. Here's the info:
JDK 1.4.2_03 Windows XP (SP 1) nVidia Quadro FX 500/600 128 MB, AGP, Aug/Sep 2004 driver dual monitor
Calls GraphicsDevice.getAvailableAcceleratedMemory() tell me there's 100MB left when application is running.
-----Original Message----- From: Chet Haase [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 7:18 PM To: Peterson, Brian Cc: [EMAIL PROTECTED] Subject: Re: [JAVA2D] lot of time in blitSurfaceData
Hi Brian,
it's pretty impossible to tell what's going on from your description. What release of Java are you using? What platform are you running on? if you're on Windows, what graphics card are you using?
All of these items (and more) contribute toward our ability to accelerate images in general and Swing's back buffer in particular.
Thanks, Chet.
Brian Peterson wrote:
I have an application that is spending 25% of its time in sun.java2d.pipe.DrawImage.blitSurfaceData 19% of which comes from paintImmediately calls from the
RepaintManager (call
trace at end of message).
Are the offscreen buffer images for my windows or
subcomponent JPanels not
getting accelerated? Or is this normal behavior?
Brian
javax.swing.RepaintManager.paintDirtyRegions() javax.swing.JComponent.paintImmediately() javax.swing.JComponent._paintImmediately() javax.swing.JComponent.paintDoubleBuffered() javax.swing.JComponent.paintWithOffscreenBuffer() sun.java2d.SunGraphics2D.drawImage() sun.java2d.SunGraphics2D.drawImage() sun.java2d.SunGraphics2D.copyImage() sun.java2d.pipe.ValidatePipe.copyImage() sun.java2d.pipe.DrawImage.copyImage() sun.java2d.pipe.DrawImage.copyImage() sun.java2d.pipe.DrawImage.RenderSurfaceData() sun.java2d.pipe.DrawImage.blitSurfaceData()
=============================================================
==============
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".
