Skip to main content

[JAVA2D] lot of time in blitSurfaceData

5 replies [Last post]
Anonymous

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 listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Brian Peterson

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:Chet.Haase@Sun.COM]
> Sent: Thursday, October 21, 2004 7:34 PM
> To: Peterson, Brian
> Cc: JAVA2D-INTEREST@JAVA.SUN.COM
> 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.
>
>
> Brian.Peterson@gd-ais.com 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:Chet.Haase@Sun.COM]
> >>Sent: Thursday, October 21, 2004 7:18 PM
> >>To: Peterson, Brian
> >>Cc: JAVA2D-INTEREST@JAVA.SUN.COM
> >>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 listserv@java.sun.com and
> >>>
> >>>
> >>include in the body
> >>
> >>
> >>>of the message "signoff JAVA2D-INTEREST". For general help,
> >>>
> >>>
> >>send email to
> >>
> >>
> >>>listserv@java.sun.com and include in the body of the
> message "help".
> >>>
> >>>
> >>>
> >>>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Chet Haase

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:

>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:Chet.Haase@Sun.COM]
>>Sent: Thursday, October 21, 2004 7:34 PM
>>To: Peterson, Brian
>>Cc: JAVA2D-INTEREST@JAVA.SUN.COM
>>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.
>>
>>
>>Brian.Peterson@gd-ais.com 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:Chet.Haase@Sun.COM]
>>>>Sent: Thursday, October 21, 2004 7:18 PM
>>>>To: Peterson, Brian
>>>>Cc: JAVA2D-INTEREST@JAVA.SUN.COM
>>>>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 listserv@java.sun.com and
>>>>>
>>>>>
>>>>>
>>>>>
>>>>include in the body
>>>>
>>>>
>>>>
>>>>
>>>>>of the message "signoff JAVA2D-INTEREST". For general help,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>send email to
>>>>
>>>>
>>>>
>>>>
>>>>>listserv@java.sun.com and include in the body of the
>>>>>
>>>>>
>>message "help".
>>
>>
>>>>>
>>>>>
>>>>>
>>>>>
>
>===========================================================================
>To unsubscribe, send email to listserv@java.sun.com and include in the body
>of the message "signoff JAVA2D-INTEREST". For general help, send email to
>listserv@java.sun.com and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".
[att1.html]

Brian Peterson

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:Chet.Haase@Sun.COM]
> Sent: Thursday, October 21, 2004 7:18 PM
> To: Peterson, Brian
> Cc: JAVA2D-INTEREST@JAVA.SUN.COM
> 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 listserv@java.sun.com and
> include in the body
> >of the message "signoff JAVA2D-INTEREST". For general help,
> send email to
> >listserv@java.sun.com and include in the body of the message "help".
> >
> >
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Chet Haase

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.

Brian.Peterson@gd-ais.com 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:Chet.Haase@Sun.COM]
>>Sent: Thursday, October 21, 2004 7:18 PM
>>To: Peterson, Brian
>>Cc: JAVA2D-INTEREST@JAVA.SUN.COM
>>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 listserv@java.sun.com and
>>>
>>>
>>include in the body
>>
>>
>>>of the message "signoff JAVA2D-INTEREST". For general help,
>>>
>>>
>>send email to
>>
>>
>>>listserv@java.sun.com and include in the body of the message "help".
>>>
>>>
>>>
>>>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Chet Haase

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 listserv@java.sun.com and include in the body
>of the message "signoff JAVA2D-INTEREST". For general help, send email to
>listserv@java.sun.com and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".