However, if I start NetBeans, then click on the webstart link I get ~100FPS.
If I then close NetBeans, and click on the webstart link, I get ~25FPS again.
Also, when I start two instances of the game, then minimize the one I started first, the second instance has ~100FPS while if I minimize the second, the first instance still has ~25FPS.
Using 1.4.0_04 and 1.4.1_01 JREs, the problem does not occur, i.e. I always get ~100FPS
[quote]So, with the d3d=false it doesn’t matter if you’re running two applications or one, you always get 110 fps?
[/quote]
From the command line, d3d=false always seems to work regardless of what else is running and gives me ~110FPS. Setting ddoffscreen=false or noddraw=true
also works, but this only gives me ~80FPS. Not setting any flags gives me ~25FPS.
From webstart, setting d3d=false seems to have no effect, i.e. I get ~25FPS unless another java app is running. Setting noddraw=true, however, does work and gives ~80FPS.
This is with 1.4.2_04. I haven’t tried 1.5 beta1 yet.
[quote]From webstart, setting d3d=false seems to have no effect
[/quote]
I suspect that the property gets set too late when set from Webstart. AWT is already active and the decision to use d3d has already been made.
I’m no driver expert but I’m pretty sure that most D3D (and to a lesser extent, OpenGL) drivers are optimized for a single onscreen context, which is their expected usage as DirectX is designed to be a games API. The D3D APIs are not specifically bad at handling multiple contexts but the implementations are, as I say, tuned to deal with the common case one one context.
When you have two contexts the continual switching between one and the other is likely to cause severe performance degradation.
The decision to use DirectX in the rendering pipeline by default for Java2D was probably unwise. There are many instances of incompatibility, poor performance, or incorrect behaviour between multiple DirectX applications onscreen.
Hm, I was under the impression GDI+ was a bit better at this sort of thing…
You’re stuck with D3D if you don’t want to use OpenGL at all (don’t use DirectDraw!) - so it seems you need to find a way to get it to function a little more optimally. It should be possible to get it to cooperate a little better that it is though, I believe.
Out of interest, why don’t you try using OpenGL drivers? You’ve got a reliable 65% of the Windows desktop then (I mean working OpenGL drivers, too). You’ve got all the code already in the Linux build. If you detect a decent OpenGL implementation you could use that as the primary path; then back off to Direct3D for the 35% that don’t have GL drivers; then finally to GDI.
This ultimately would be of great benefit to you I think as your Mac and Linux codebases should be near identical. This will let you take care of the vast majority of desktop systems out there with one code path. (And remember we are talking very basic OpenGL functionality requirements here - no shaders or crazy stuff like that).
Need I also suggest that touting OpenGL as the primary accelerated API of choice on desktop systems will probably make the OEMs sit up and take a bit more notice of the proceedings.
[quote]Out of interest, why don’t you try using OpenGL drivers? You’ve got a reliable 65% of the Windows desktop then (I mean working OpenGL drivers, too).
[/quote]
Isn’t the problem deciding whether the OpenGL is reliable as opposed to just being present? Perhaps have a table of driver versions which are known to be adequate.
What a coincidence, I have such a table It’s more or less the case that any GL driver advertising version 1.3 capability or above will be able to accelerate Java2D operations without problem.
[quote]What is your video board? What DX, driver version?
[/quote]
------------------
System Information
------------------
Time of this report: 3/17/2004, 22:04:48
Machine name: D1QDQL0J
Operating System: Microsoft Windows XP Home Edition (5.1, Build 2600) Service Pack 1 (2600.xpsp2.030422-1633)
Language: English (Regional Setting: English)
System Manufacturer: Dell Computer Corporation
System Model: Dimension 2350
BIOS: IntelR - 42302e31
Processor: Intel(R) Pentium(R) 4 CPU 2.50GHz
Memory: 254MB RAM
Page File: 208MB used, 417MB available
Primary File System: n/a
DirectX Version: DirectX 8.1 (4.08.01.0810)
DX Setup Parameters: Not found
DxDiag Version: 5.01.2600.1106 32bit Unicode
---------------
Display Devices
---------------
Card name: Intel(R) 82845G/GL/GE/PE/GV Graphics Controller
Manufacturer: Intel Corporation
Chip type: Intel(R) 82845G Graphics Controller
DAC type: Internal
Device ID: Enum\PCI\VEN_8086&DEV_2562&SUBSYS_01471028&REV_03
Display Memory: 64.0 MB
Current Mode: 1024 x 768 (32 bit) (60Hz)
Monitor: Dell E151FPp
Monitor Max Res: 1024,768
Driver Name: ialmrnt5.dll
Driver Version: 6.14.10.3691 (English)
DDI Version: 8 (or higher)
Driver Attributes: Final Retail
Driver Date/Size: 10/8/2003 10:12:28, 36927 bytes
Driver Signed: Yes
WHQL Date Stamp: n/a
VDD:
Mini VDD: ialmnt5.sys
Mini VDD Date: 10/8/2003 10:11:20, 93979 bytes
Device Identifier: {D7B78E66-6622-11CF-F37D-4D21A2C2CB35}
Vendor ID: 0x8086
Device ID: 0x2562
SubSys ID: 0x01471028
Revision ID: 0x0003
Registry: OK
DDraw Status: Enabled
D3D Status: Enabled
AGP Status: Enabled
DDraw Test Result: All tests were successful.
D3D7 Test Result: All tests were successful.
D3D8 Test Result: All tests were successful.
[quote]Does your app set sun.java2d.translaccel property?
[/quote]
No
[quote]Also, could you please run your app from the command line with -Dsun.java2d.trace=count, let it run for a while, then quit and post the output.
Then, start some other java app (netbeans or whatever), and run your app with the tracing enabled.
[/quote]
Trace from first instance started, ~28FPS
And from the second instance, running while first instance is minimised ~95FPS
Someone from Sun (Chet?) has already stated that a the OpenGL pipeline IS being maintained in the Windows code base… and that perhaps some time in the future it could be included in the Windows JRE release.
I got the impression that it was simply the fact that there is no time to work out the kinks on Windows given that Windows already has acceleration through D3D and DirectDraw.
Too bad driver writers aren’t more accountable for the problems they cause for everyone else.
I’ll leave it to Chris to ramble about the quality of OpenGL drivers on windows, especially on non-nvidia boards.
Unfortunately for us, not everybody has the latest Nvidia board with the latest drivers. In fact, the majority have some kind of on-board intel i8xx stuff, and opengl there doesn’t fly (nor does d3d =).
Anyway, we too, think that we should have a complete D3D pipeline (no ddraw), because now we do too much switching between ddraw (blitting, locking), d3d (lines, rects, texture blits), which kills the performance.
It appears that in the second case we don’t use d3d as much (I’m guessing because of some kind of drivers issue) for rendering rectangles/lines, and it works better as there is not as much context switching.
I’m not sure if we’ve tested on this particular board, I’ll check tomorrow.
Unfortunately, I don’t think the fix for this would be straightforward, and it’s very doubtful it’ll make it into 1.5.
The correct fix would likely involve rewriting our rendering pipeline on windows to use only D3D (or OGL)…
