2D Game performance severely degraded on upgrade from Java 5 to 6

Java 2D
#1

Hi

My employer sells a Java 2D based game into the education market. I’m getting rather a lot of reports from customers of really slow performance in our app after upgrading to Java 6. It appears the frame rate is more than halved. Running in Java 5 it seems all is ok.

I haven’t been able to collect much data on the situation yet, but it seems one common thread may be Intel or SIS graphics hardware, although this is based on feedback from about 5 of the many cases I have.

I wasn’t able to find anything obviously relevant in the Java bug database. Is anyone else aware of a problem? Why would it run fine in Java 5 but not in Java 6 where in all other cases we’ve found performance to be much much better?

Our app uses Full Screen Exclusive mode, a BufferStrategy with 2 buffers, and the problem has been reported on Windows XP only at the moment.

Cheers

#2

Which version of Java6 are we talking about?

One guess is that Java 6 uses the (old version of) Direct3D pipeline when
in full-screen mode. That may have backfired somehow on Intel or SiS chips
(providing that the d3d pipeline was indeed enabled on those boards)
since they really do suck in d3d.

Could you ask your users to set J2D_TRACE_LEVEL=4 env. variable
prior to starting your application if possible and collect the output
in the console (providing they start it from the console)?

A workaround would be to set -Dsun.java2d.d3d=false and see if it helps.

Thanks,
Dmitri

#3

could this problem be anyway related to http://www.java-gaming.org/forums/index.php?topic=18327.0 ;D

#4

Thanks for the response guys.

Yes sorry euan is my colleague so this is the same problem. We can consolidate his question here. Sorry about the duplication. :-[

They will be using Java 6 consumer JREs. Any of 6u2, 6u3, and maybe some on 6u4.

I’ve done a bit of research. If my understanding is correct, Java 6 introduced the Direct3D pipeline and made it default for Fullscreen mode even though the old DirectDraw/GDI one was still default in windowed/desktop mode. Is that correct? So to go back to the Java 5 behaviour we explicitly disable the Direct3D pipeline.

Our app starts using Launch4j/javaw on Windows so I think I’ll try disabling the D3D pipeline first and see if that helps. But I will endeavor to get some trace logs to see if the real problem can be diagnosed. I have the usual problem - all folks affected by this are remote ::).

Thanks for the suggestions. I’ll come back when I know more.

#5

I’ve done a bit of research. If my understanding is correct, Java 6 introduced the Direct3D pipeline and made it default for Fullscreen mode even though the old DirectDraw/GDI one was still default in windowed/desktop mode. Is that correct?

Yes.

Dmitri

#6

Good news. I’ve been told that -Dsun.java2d.d3d=false has solved the problem on a machine with a Mobile Intel 915GM/GMS graphics card. I will now try to conjure up a way to get a 2D trace log on that machine.

#7

Yeah, I’m pretty sure Intel chips were faster w/o d3d than with d3d.

The 915-(and 945) chips don’t have much d3d hw acceleration,
even the latest ones (G35, X3000) are rather sucky (and with
buggy drivers).

Dmitri

#8

One thing, though. If you disable the d3d unconditionally, the new Direct3D 9-based
pipeline in the upcoming 6u10 will also be disabled, which would be
unfortunate.

It may be a good idea to provide a user with a choice if possible, or may
be base you decision on the java version (I know, that sucks).

Thanks,
Dmitri

#9

Yeah I don’t want to disable the D3D pipeline unless necessary. We had some schools who had lockups in Java 5 which were solved by upgrading to 6 so I don’t want to risk reintroducing that problem if it was indeed caused by the rendering code (I’d share more about that problem but to be honest I’ve no idea what caused it - the pupil login accounts were so strictly locked down it was impossible to get any debug info out at all - solved purely on trial and error).

Ideally we’ll make this a user prefs setting in the apps options.

If we were to set that system property at runtime from within the app itself (e.g. in main() or as we load our user prefs) how late in the startup process could we do it and still have it seen and processed by the graphics subsystems? Will it work as long as we set it before we create the first frame? Or can we set it at some point later?

#10

You should set it before any GUI stuff is initialized. That
includes accessing GraphicsEnvironment, etc.

How do you distribute your application? If it’s through Webstart,
you can create two jnlp files with attributes - one for “accelerated”
case, another for “safe” one.

If it’s just a jar file that they run then you’ll need a way to save your
preferences (since once the use choses a setting via the gui it will
be too late to change it for the the current vm), and restart the app.

In one project I had a little “starter” app which allowed the user
to chose the settings, and then exec-ed a new JVM with
and passed the properties as arguments.

If it’s an applet, then unfortunately you’re out of luck
until 6u10 comes out (where you will be able to specify
vm options for applets).

Dmitri

#11

I have a lot of problems with this graphics hardware too. I use Java 1.6. Some 3D objects don’t appear at all when using alpha blending with SIS, the Z-buffer max depth is very small :frowning: , the game crashes when creating a VBO with Intel, it is not really fast when it doesn’t crash.

#12

Interestingly I’ve been told 6u10 runs nice and fast on the Intel 915 machine. No need to disable D3D at all. I will try to get some J2D trace logs from that machine running with the different Java versions.

#13

That’s because 6u10 disables the D3D pipeline on Intel chips. They have bugs
in the drivers which restart the machine =(

We’re working with Intel on resolving this and re-enabling the pipeline.

Dmitri

#14

Oops, so we do need to do something about this then, as if you resolve the current reboot-bugs with Intel and re-enable D3D we could see this problem return right?

#15

The new pipeline will not be enabled for 915 chips anyway - which
is where you saw the problem, right?

If anything, we would only enable it for 965 (aka X3100), when
they fix their driver bugs. They seem to be taking their time though.

You shouldn’t need to do anything - we won’t enable it unless it works well.

Dmitri