Vista+Java2D - Performance useless + Vsync doesn't work?

Java 2D
#1

Vista Premium (3d desktop disabled - crap waste of resources), Geforce 6800GT *almost latest drivers. (163.44, updating to 163.75 as I type)

Using my ancient Balls.jar benchmarking tool (written way back in Java1.4) - A completely blank 1280x1024 screen now renders at just 37fps.

In XP I would be able to render ~3000 images @ 37 fps.

Any ideas? Java Bug? Vista Bug? Driver Bug? Configuration Bug?

:edit:

oh, and JRE 1.6.0_01

:edit:

Unsurprisingly latest 163.75 drivers made no difference.

:edit:

Turning Aero back on makes fek all difference either.

#2

In JDKs prior to 6u10 (aka 6uN, jdk6.dev.java.net) hw acceleration is disabled on Vista
because of compatibility issues =(

In 6uN the new D3D pipeline is enabled on Vista - please try and report
your experience.

Thanks,
Dmitri
Java2D Team

#3

Nice!

1280x1024 11000 images @ 60fps :smiley:

Though it looks like acceleration is disabled in windowed mode?
Also fill polygon, oval, and round rect are not accelerated either?

Also, fullscreen exclusive mode has an odd effect on my 2nd monitor - causes it to go completely black until something triggers a desktop repaint. (I say odd, as no other D3D apps do that)

#4

It should be enabled in windowed mode, too.

Could you run with -Dsun.java2d.trace=log and post the output?

Does your app use BufferStrategy or VolatileImage for back-buffer?

All of those are accelerated. Pretty much everything is (except xor).
Make sure you have the latest driver, too.

Same, try with logging to see what’s being called.

And could you please run with this env. variable set:
set J2D_TRACE_LEVEL=4
and post the output?

Other d3d apps have no idea about your second monitor =)
This is probably because we create a d3d device per each
monitor, and when you enter fs mode all of them have to be
reset.

Dmitri

#5

Ah, worked out the cause.

When using BufferStrategy(3) in Windowed mode it loses hardware acceleration - a BufferStrategy with just 2 buffers works ok.

With 3 buffers, it seems to fall back to using :-
sun.java2d.loops.Blit::Blit(ByteIndexedBm, SrcOverNoEa, IntRgb)
instead of :-
sun.java2d.d3d.D3DTextureToSurfaceBlit::Blit(“D3D Texture”, AnyAlpha, “D3D Surface”)

Looks like I was wrong about fill polygon, oval & round rect - they are using the D3D fillPath loops.
It’s just the D3D loops don’t appear to be very much faster than the java2d software loops.

software ~1250 fillRoundRects @ 30fps (sun.java2d.loops.FillPath::FillPath(AnyColor, SrcNoEa, AnyInt))
d3d ~1750 fillRoundRects @ 30fps (D3DFillPath)

Infact, in the case of fillPolygon the D3D loops are quite abit slower than the software loops!

software ~4700 fillPolygon @30fps (sun.java2d.loops.FillSpans::FillSpans(AnyColor, SrcNoEa, AnyInt))
d3d ~3050 fillPolygon @ 30fps (D3DFillPath)

#6

Yeah, 3 buffers aren’t supported with certain Flip modes.

As for the performance of the loops - that’s surprising.
In my tests they were faster, but I guess it depends on
the configuration.

Did you test with your ‘balls.jar’ ? (that came out weird =)

Also, one good thing about d3d loops is that you get
alpha compositing + transforms pretty much for free. Doesn’t help
much if you aren’t using those, of course.

Dmitri

#7

I just tried the same test on a new machine(intel Q6600 quad core with GF8800GTX),
and fillPolygon is again faster through the software loops than it is through hardware.
This is under XP rather than Vista this time.

#8

Well polygons are rendered sending down “spans” to the graphic card - a span is a rectangular part of that polygon.
So first there’s quite some CPU overhead generating those spans from the polygon supplied by the user and second there’s quite a high per-primitive overhead for drawing operations with todays drivers/systems. And because a polygon can result in many spans, a lot of per-primitive overhead happens here :-/

lg Clemens

#9

All is true, but we do try to batch things up a lot which usually
helps.

Dmitri

#10

this sounds horribly inefficient, why segminting it in spans and not send the polygons directly to opengl or directx?

#11

You can not send the polygons directly. You first would need to segment them into
triangles, which would require changing the way our software pipeline works.

Certainly not impossible but a bit out of the scope for this
release.

Dmitri

#12

Maybe a bit off-topic, but why doesn’t java.awt.Graphics have ‘native’ support for triangles (not using java.awt.Polygon)

#13

I guess triangles were considered more of a 3D kind of primitive.

Dmitri

#14

Though j2me/midp2 has fillTriangle… but no drawTriangle :slight_smile:

I guess when designing awt Graphics they believed offering just the super-set behaviour of polygons was sufficient.
It would certainly fit with the philosophy behind java1.2s Shape & Area classes