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.

One guess is that Java 6 uses the (old version of) Direct3D pipeline whenin 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. variableprior to starting your application if possible and collect the outputin the console (providing they start it from the console)?

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

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

Quote

One guess is that Java 6 uses the (old version of) Direct3D pipeline whenin 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.

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.

Quote

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

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

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 .

> 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?

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.

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?

You should set it before any GUI stuff is initialized. Thatincludes 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 yourpreferences (since once the use choses a setting via the gui it willbe 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 userto 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 luckuntil 6u10 comes out (where you will be able to specifyvm options for applets).

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 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 , the game crashes when creating a VBO with Intel, it is not really fast when it doesn't crash.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org