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:
>
> >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".

Reply via email to