Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  2D Game performance severely degraded on upgrade from Java 5 to 6  (Read 3718 times)
0 Members and 1 Guest are viewing this topic.
Offline munckfish

Junior Newbie





« Posted 2008-03-11 15:58:46 »

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
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #1 - Posted 2008-03-11 18:44:32 »

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
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #2 - Posted 2008-03-11 19:56:01 »

could this problem be anyway related to http://www.java-gaming.org/forums/index.php?topic=18327.0  Grin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline munckfish

Junior Newbie





« Reply #3 - Posted 2008-03-12 17:52:54 »

Thanks for the response guys.

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

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

Which version of Java6 are we talking about?

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

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

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  Roll Eyes.

Thanks for the suggestions. I'll come back when I know more.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #4 - Posted 2008-03-12 17:59:24 »

> 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
Offline munckfish

Junior Newbie





« Reply #5 - Posted 2008-03-13 18:51:05 »

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.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #6 - Posted 2008-03-13 21:54:44 »

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
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #7 - Posted 2008-03-13 21:56:23 »

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
Offline munckfish

Junior Newbie





« Reply #8 - Posted 2008-03-14 19:18:42 »

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

Senior Member




If only I knew what I'm talking about!


« Reply #9 - Posted 2008-03-14 19:33:29 »

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
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online gouessej
« Reply #10 - Posted 2008-03-17 12:53:25 »

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

Offline munckfish

Junior Newbie





« Reply #11 - Posted 2008-03-26 10:40:28 »

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.
Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #12 - Posted 2008-03-27 18:17:34 »

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
Offline munckfish

Junior Newbie





« Reply #13 - Posted 2008-04-17 14:01:17 »

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

Senior Member




If only I knew what I'm talking about!


« Reply #14 - Posted 2008-04-18 06:11:35 »

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
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (20 views)
2014-07-29 18:09:19

Riven (13 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (31 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (28 views)
2014-07-23 21:07:15

Riven (29 views)
2014-07-23 20:56:16

ctomni231 (60 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!