Improving draw performance for constantly changing image

[ctomni231]

did you try Thread.sleep() to reduce the CPU time? There really is no other way to prevent the 100% CPU except by forcing the CPU to rest… (or using a RESTful system )

[EdTorbett]

@ctomni231

did you try Thread.sleep() to reduce the CPU time? There really is no other way to prevent the 100% CPU except by forcing the CPU to rest… (or using a RESTful system )

I use a combination of Object.wait()s, PriorityBlockingQueue()s and Thread.sleep()s as appropriate. The CPU usage isn’t a constant 100% - it varies depending on work done and unfortunately, java2D is doing more work than it needs to

You also refer to RESTful - are you referring to the web service architecture? Because if so, I’m afraid I don’t see the relevance. Even web frameworks gotta sleep (or wait, or select…)

[jonjava]

@EdTorbett

@jonjava

http://www.java-gaming.org/topics/java-media-player/27100/view.html

The annoying part is that I’ll have to re-implement all of the Swing components that I overlay onto the video in openGL (these aren’t included in the benchmarking above, they were the first thing I suspected and removed when testing the performance), unless anyone can suggest otherwise?

IIRC JOGL works with Swing to some extent, maybe that might help?

http://jogamp.org/jogl/doc/userguide/#overview
https://jogamp.org/wiki/index.php/Using_JOGL_in_AWT_SWT_and_Swing#JOGL_in_Swing

[CommanderKeith]

@EdTorbett

Oh, my previous traces had quite a lot of extra stuff in them (debug overlay text etc) that for simplicity’s sake I’ve commented out. Here it is with literally just the image render:

With D3D enabled:

862 calls to sun.java2d.d3d.D3DSwToSurfaceScale::ScaledBlit(IntRgb, AnyAlpha, "D3D Surface")
16 calls to sun.java2d.d3d.D3DMaskFill::MaskFill(AnyColor, SrcOver, "D3D Surface")
863 calls to sun.java2d.d3d.D3DRTTSurfaceToSurfaceBlit::Blit("D3D Surface (render-to-texture)", AnyAlpha, "D3D Surface")
5 calls to D3DFillRect
1 call to D3DDrawGlyphs
1747 total calls to 5 different primitives

With D3D disabled:

627 calls to sun.java2d.loops.ScaledBlit::ScaledBlit(IntRgb, SrcNoEa, IntRgb)
629 calls to sun.java2d.windows.GDIBlitLoops::Blit(IntRgb, SrcNoEa, "GDI")
31 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, SrcOver, IntRgb)
3 calls to sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
1290 total calls to 4 different primitives

Please note they weren’t run for exactly the same amounts of time, so numbers may vary.

sun.java2d.loops operations are the software blitting, and in your output for D3D it looks like none of that is going on which is good.
But in your D3D output there is a lot of:
862 calls to sun.java2d.d3d.D3DSwToSurfaceScale::ScaledBlit(IntRgb, AnyAlpha, “D3D Surface”)
“Sw” stands for software I believe, so this may be the slow operation that is bogging down the CPU and frame rate.
I am not an expert on java2D and most of my knowledge is just from experimenting with different things and some reading, but I have found that VolatileImages are a little faster than BufferedImages. So you could try switching to them.
Another thing, fullscreen exclusive mode with D3D on and triple buffering may result in much faster speeds since page flipping is likely to be enabled.
Another thing, there is a java2d class that is supposed to give details of graphics capabilities but it is buggy and won’t actually tell you if page flipping is possible or not.
Unfortunately Java2D has not been worked on for some time and all of oracle/sun’s energy has been put into javafx, though there is little to show for it.

[EdTorbett]

I’ve replaced my earlier post containing dropbox links to the profiling results with the actual image to increase visiblity as I assume people haven’t noticed them.

Essentially, the problem isn’t in any one command such as the surface scale/blit in d3d; it’s in the mandatory buffer flush immediately following. Turning off d3d and using the software blitting is actually faster for displaying the image alone as it’s not doing this extremely expensive operation, for whatever reason. Unfortunately the gains on image rendering are lost in the general reduction in performance with d3d switched off.

[CommanderKeith]

Java2d graphics pipelines are a part of the VM and are not configurable beyond the few vm args you already know about.

[quote]Each time a new frame is decoded, the data is copied into the raster and repaint(30) called (to trigger an asynchronous swing repaint
[/quote]
Perhaps using active rendering might work better, bit then again it may be negligible.

Why dont you try switching to OpenGL and see how it goes?