www.jpct.net
General => News => Topic started by: EgonOlsen on January 17, 2008, 01:14:11 pm
-
Hi all!
I was just playing around with the early access version of Update10 (http://download.java.net/jdk6/binaries/ (http://download.java.net/jdk6/binaries/)), it has a new D3d-pipeline for Java2D (for Windows)...and it sucks. So just in case anybody is using this in combination with the software renderer, make sure to disable that new pipeline in case of performance problems by doing a -Dsun.java2d.d3d=false
On my test machine, the performance degrades to 50% of what the normal (or the OpenGL-) pipeline could deliver with that shiny new pipeline.
-
Hi
ouch ... and this pipeline is turned on by default? Sounds like a step into the wrong direction;D
Thanx for the hint
-
ouch ... and this pipeline is turned on by default?
Yes, it is. But this is only an early access version, it's not a final release and it does work fine with the OpenGL-pipeline instead which should basically do the same thing, so i hope that this behaviour can be fixed. I've already opened a thread in the corresponding forum at Sun (http://forums.java.net/jive/thread.jspa?threadID=35484&tstart=0 (http://forums.java.net/jive/thread.jspa?threadID=35484&tstart=0)).
-
I don't quite understand why anyone is interested in a d3d pipeline for java anyway..I mean..after all AWT should be platform independent :).
Especially for a 2d toolkit..oh well..
-
I think it's about performance. Some operations like transparency and scaling are much faster when done using a 3D pipeline.
-
Yes but that should be possible to do using an OpenGl pipeline as well..at least to my humble understanding ;D.
Java3d also offers a direct3d modus which is used by quite a few people. Kinda wierd..since it's not possible to access it directly anyway...so I guess there must be some kind of gain when using d3d on windows or some such..
-
Better driver support maybe. OpenGL drivers usually lack in quality when compared to D3D drivers.
-
Plus Microsoft provides D3D drivers for most cards when installing Windows but no OpenGL drivers. You have to use the vendor's drivers to get proper OpenGL support. Maybe not all users are doing this.
-
Update on the situation: They've filed a bug report for this after i had submitted a simple test case. I'll post a link to the bug once it appears on the list. I really hope that things can be improved, because otherwise, they've seriously damaged per-pixel stuff.
-
Well I guess best is to turn it off by default ;D.
Wouldn't something like this in the main class help?
static
{
if(System.getProperty("os.name").contains("Win"))
{
System.setProperty("sun.java2d.d3d", "false");
}
}
That should work for applets too
-
Yes, that would work. The question is, if that works in an applet, because the VM may initialize the pipeline before actually giving control to the applet...i'm not sure about this. The new applet plugin in that update supports VM parameters, so that would be another place to add it. However, one have to know that this is needed, and not everyone will. The idea of a default d3d-pipeline just sucks imho.
-
The idea of a default d3d-pipeline just sucks imho.
Agreed ;D
-
Ulp! Will this affect Runescape & Bloodridge? :-[
-
Yes, it will. But it's not a problem on all systems. But on some (like the AGP one that i used for testing), it's a killer. At SUN, they seem to test their Java2D changes on one or two machines IMHO and they keep ignoring that we are NOT taking about 10% slower compared to the current, official release but about 10% of the blitting performance. But because it's a problem with the way D3D works, i don't think that the situation will improve. Luckily, you can disable the pipeline even in applets when using the new applet plugin, which will be available for IE and FF3 (but not for FF2).
If you don't like this, vote for the bug (http://bugs.sun.com/view_bug.do?bug_id=6652116 (http://bugs.sun.com/view_bug.do?bug_id=6652116)). It might not help but it doesn't hurt either.
-
OK I voted for it! That's bad news for me! :(
-
Update 10 is final, so it's time to revive this thread. To make it short: It still sucks! Blitting performance goes from 100% of the speed of the former version down to 10%...it depends on the system. On one of my machines with an AthlonX2 4400+ and a GeForce 7600GT AGP, the fps drop from 56 to 35fps with this piece of crap they call a 2d-pipeline. I don't know how to handle this. Disabling this pipeline by default inside of jPCT like mentioned in this thread isn't a good idea IMHO...but leaving it on isn't one either... >:(
-
A compromise might be to write something in the Javadocs and/or print out a message to the Java Console when jPCT starts, stating something like "If experiencing crappy framerates, try disabling the d3d pipeline."
-
I just installed update 10 and my game seems to run alright on my computer. I also ran dmouses game and it seemed to run just as well if not a little better. This is bad news, though. How come it's slower? I thought d3d was supposed to speed up 2d blitting? BTW, I think there's a patch from AMD concerning some types of cross platform games and Athlon 64. I downloaded it, but I can't remember what it was now. Not sure if it would relate to this or not. It had to do with bad frame rates, though.
edit: looked it up. It's called the AMD dual core optimizer. About the middle of this page:
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_9706,00.html
-
The dual core optimizer has nothing to do with this. It's for synchronizing the cpus' clock tick counter between the two core, so that a timing that relies on it doesn't go wrong when the scheduler shifts the application to another core (which the windows scheduler does all the time). The problem with the d3d-pipeline has something to do with an access problem to the pixel data in the frame buffer. The bug that is linked to an earlier post describes it pretty well.
-
OK. I don't know what you should do either, really. It seems to work just fine on my system. I can't remember what frame rate I was getting in the FPS example, but I went back and ran it and it was adequate and seemed as fast or possibly a shade faster than it had been the last time I tried it in software. If it doesn't actually make it faster, it might be better to just turn it off in jpct and leave an option for the author to turn it back on and do another solution if he chooses like some kind of start up option or something. Maybe we could do some tests on our different systems with it turned off and see if it matters or not.
-
Well, if that can be enabled or disabled it should be able to do it in execution time, becausse it differs from machine to machine, to maybe it should do a small test with the first calls to display and cheking that it should take the desicion. Maybe?! :o
-
But you can't disable it once it's initialized, and you can't test without initializing it...and so you are trapped. I think i'll add an option to config and a warning and that's it.