Java3d speed collapse caused by other java apps running at the same time

Question

Hi
I am programming a flightsimulator for some months.
The current state is online available (all free, no copyrights)
at http://www.snowraver.org/efcn/efcnsim/index.htm
especially the sample (source) which shows the
behaviour which is the reason for my post is here
http://www.snowraver.org/efcn/efcnsim/page2.htm
My Problem:
When I start the sim while two other java programs
( one is a server running localhost, one is a client )
are running, the speed of the flightsim is very slow,
one frame update takes 3 to 5 seconds.
( 3 java.exe's in task list plus 1 which is the IDE )
When I start the flightsim ALONE, I have 30 to 40 frames per second.
( 2 java.exe's in the task list = the flightsim and the IDE -> no prob here )
That means, the flightsim is about 100 times slower, when
started while the other two apps are running.
BUT the other two applications do almost ***NOTHING***, the
CPU load is 1 or 2 percent.
Of course they have threads running, but all are waiting
for a signal - no thread really consumes CPU power.
Interestingly, when I FIRST start the flightsim and AFTER THIS
start the two other applications, the flightsim
holds 30 frames per seconds without problems, even
though the other applications consume some CPU power
until they have completely started up.
Configurations:
JSDK 1.4.2_1 , 0_2..
Java3D 1.3.1 OPENGL (The DirectX version crashes with D3D device lost)
Win2000,XP CPU 800MHz upto 3 GHz
In my point of view, the java3d thread scheduler makes
some funny decisions when it starts up, which lead
to the order dependent behaviour described above.
My question is, if anyone has some ideas, how I could
get away from this speed collapse.
The problem is caused in native code I guess.
I also could imagine, that it has to do something with
the order in which one creates, attaches and starts
the Canvas3D. (? could produce race conditions)
The flightsim runs in full retained mode. Of course
the CPU work in the behaviours is rather big, because
the ROAM triangulation update (..) is done there
and the triangles are recalculated and passed
( all BY_REFERENCE ).
Or could it have to do something with the memory
consumption ( when all runs, almost all of
the 512MB RAM is taken by the three java.exe's ) ?
Any hints or ideas ?

Answer 1

:) No, Sun does handle it [lol]
I just have tested it on my computer at work
( 3GHz HP compaq, 1GB Ram and a Intel 82865G Graphics
Card with 64MB memory, Windows XP )
and it has worked without problems any way I tried.
( Except for xclusive fullscreen mode, but I guess, the administrators
have deactivated it somehow, so we don't play games at work :)
I couldn't test it under Linux so far, but I think, this will be less
problematic than Windows [usually].
However my current assumption is:
I totally have forgot the [limited] videocard memory.
I suppose, Java3D tries to put all triangle data and all
textures to the videocards memory, so most data processing
then can be passed to it's graphiccard CPU using
OpenGL commands.
Now the flightsim produces a varying amount of (by_reference) triangle data ( a few thousands )
and has some texture maps for the terrain, the sea and other things,
plus indexed triangle data for the planes and ships.
The notebook system, which slows down has an ATI Mobile Radeon card
with only 32MB RAM onboard, whereas the others have 64MB Ram.
An additional pointer to that theory is that I can trigger the slowdown by resizing
the flightsim window, while it is running.
On the notebook, it holds 30fps, until the window exceeds a size of 962*862 pixels.
At this size the speed collapses and goes down to 1 frame update every 4 seconds.
If I make the window a few pixels smaller, the speed of 30fps immediately
is there again.
Therefore I guess, some data passed to the graphic cards memory depends
linearly from the canvas3d's window dimension, and at some limit,
the graphiccard's memory is too small and Java3D changes it's strategy
and performs most calculations on the computer's mainmemory,
which of course is a lot slower.
I'm not very sure about that, I'm just speculating.
Next thing I will try is to disable directdraw for the other two applications,
possibly swing also uses graphicscard memory, when directdraw is enabled.
The solution seems to be clear anyway: The flightsim must examine the system
and set some parameters depending on the machine's capabilities.
Onboard videagraphic ram is one of them. If it's too slow, I start to decrease
the window size and expect to see a sudden increase of speed, as soon as
the rendering can be done by the graphicscard CPU. If this never happens,
I assume no OpenGL accelerator is present on that system. This can be seen as a method
for finding out the amount of videocard memory on a system by trial and error ..?:)
Thanks for your tips, Alain.
I especially have to check out the data sharing class in 1.5.