Hi,
I just tried to get two views with each having its own Universe, Canvas3D and renderthread up and running.
Everything is fine as long as there is no object in the second scenegraph. But with only a single object the memory usage of the java process explodes by about 5-10 megs per second.
I have no idea about what the cause of this problem is but perhaps someone else has more experience or has two views up and running without any hazzle.
Any ideas ?
Ca$
udpate:
whenever the second rendering thread calls view2.renderOnce about 1 MB is allocated.
I have no idea where to look for the source of this problem 
Start with View.java?
Well, at least I verified that it is not a JOGL problem. JOGL can deal with more than one GLCanvas which means it must reside somewhere else.
Can you use a tool to view where the memory is being allocated? Maybe just running the profiler on your code?
If you want to know more about how the Xith3D render pipeline works, you can check out my diagram: http://xith.org/RenderPipeline
Will.
Hi,
after quite a lot of debugging until 2.30am last night I have possibly discovered the cause of the problem:
The Texture was the suspected culprit :o
I first checked the HelloXith3D demo and extended it to use two Canvas3D and it worked fine (just as the JOGL demo extension did).
Then I changed my own code to match the modified HelloXith3D demo step by step until they matched almost line by line but I still had my memory leak.
The only difference was that my object used a texture (mapped to 6 separate faces on a cube).
The problem occurred when the same texture (instance) was used in both displays simultaneously. When I used a different Texture on the object in the second display (Canvas3D) the memory leak was no more.
As a workaround to get two identical textures in both displays I tried to load the same texture (same by filename) twice into two Texture instances but this seems not to work. Perhaps Xith is keeping a hash of loaded texture filenames to prevent double loading. Duplicating the texture file with a different filename does work (perhaps a link would do the trick too).
@Will:
The memory leak could not be on the java side since I use default heap size and this was one hell of a memory leak. After a few seconds it was getting difficult to move the mouse to reach the shell to end the process. And there was no OutOfMemoryError thrown by the java VM.
Kudos for the Xith3D coders as I checked a lot of well written code last night. The documentation is a bit sparse but the code is well readable 
Ca$
(Starship Trooper mode: Only a dead bug is a good bug !)
I have not looked into this matter any further but by the rate of memory leaking I suspect that the texture is allocated over and over again on the native GL side for each access.
Perhaps the texture is somehow bound to a single Scenegraph ?
Ca$
Well done finding the bug! These ones are tough little buggers to catch.
You are right about Xith3D caching textures when you load them in the default way. This is both good and bad, the catch is that it uses the filename as the identifier and not the full path, so you will have problems if you have two different images with the same file name (in two different directories). This should be documented better so people who don’t want to use it will realise. There also exist Texture loading methods which don’t do any caching so you could use those instead.
Does JOGL support having the same texture used on two canvas’s? Regardless, it does sounds like a JOGL bug to me as you should either be able to do it or be prevented from doing it. As you said, if it was on the Java (i.e. Xith3D) side, an OutOfMemoryError would be thrown.
Have you tried using the latest version of JOGL? Xith3D is normally several months behind. The new version may break other Xith3D features however, so be warned!
Will.
here is Ken Russel’s reply (JOGL) to this:
The problem is probably that you’re trying to use a texture object defined in one OpenGL context that isn’t defined in another. If you want to use the same texture object in multiple contexts then you have to set up sharing between those contexts, which you can do with the appropriate factory method in the GLDrawableFactory.
got a patch? ;D
I’m glad it’s possible, but it really shouldn’t leak like that when you do it wrong. Isn’t this the point of a nice cushy java wrapper?
Will.