What is the easiest way to stop automatic updates?

[STRESS]

It seems to me that when you change something on a SceneGraphNode like its appearance or geometry, remove/add a node, texture or whatever it auto triggers a rerender of the whole scene. Is there an easy way to prevent that from happening, because sometimes you might want to change SceneNodes from a different Thread. I've got this actually quite frequently since I am running currently in a SWT environment (SWT event loop is on a different thread than AWT/Swing) and this will cause sometimes some serious havoc my guess is because I am editing nodes while the render traversal is trying to render them at the same time. I've seen effects like screwed up vertex coordinates, textures & labels suddenly disapearring, etc.

Basically I want to make sure everything has been changed and then manually call render on the Viewer.

[gunn]

The automatic updates are caused by an instance of class de.jreality.util.RenderTrigger which gets created by default. If you don't want the RenderTrigger to be created, then set the following option to the VM: -Dde.jreality.ui.viewerapp.autoRender=false . Or, you can do the following in Java code before you create an instance of JRViewer:

Code: Select all

Secure.setProperty(SystemProperties.AUTO_RENDER, "false");

Then the RenderTrigger won't be created, and you'll be responsible for triggering re-rendering when things change in your scene graph.

You might choose to add your own RenderTrigger too, one that you can control more carefully. See the JavaDoc or the source file for details on how to use it.

[STRESS]

Excellent! I give this a try!

[STRESS]

That solved a lot of problems but not all. Until I spend sometime to deeply investigate why I am loosing textures (either my own ones or generated from labels). And I came across following potential culprit. So I wanted to ask if that design is delibrate since I don't fully understand what's going on in there. So I wonder if someone from the jReality team can help me to put some light on this, before I cause more problems when changing it.

When I look at Texture2DLoaderJOGL.java it is holding a big WeakHashTable referencing the GL (context) object with a list of TextureIDs (defined in that context I guess) and ImageData.

Whenever a new texture is generated in render(...) method it goes through the list of these references which seem to be obsolete (?) I don't know enough about WeakReferences in Java though. And checks if it can replace one of these or not. If it can't it will remove the reference and delete the texture from the context. So far so good.

But what I notice it even deletes references from a different GL context than the current one that it is generating the new texture for, if it can not replace it. This can't be right? Can it? At least that would explain why sometimes my texture disappears because I've got multiple instances of jReality in my application in different canvases

[steffen]

But what I notice it even deletes references from a different GL context than the current one that it is generating the new texture for, if it can not replace it. This can't be right? Can it? At least that would explain why sometimes my texture disappears because I've got multiple instances of jReality in my application in different canvases

Well the idea is to delete all textures corresponding to dereferenced ImageData objects. The ReferenceQueue gives references to all unreachable ImageData. Then the corresponding GL textures are deleted, independently of the GL context. This behavior is correct, because for instance textures living in a dereferenced/unused GL context would not be deleted otherwise. But the code seems not to deal with the possibility that different contexts may produce the same texture id for different ImageData, and it also ignores that the same ImageData may need to be rendered from different GL contexts. It seems that we need to rewrite the code. Maybe it would make sense (and improve the code) to make Texture2DLoaderJOGL a class and create an instance for every Viewer...

[steffen]

I looked into the code again, I think the Texture2DLoaderJOGL class should become a field in JOGLRenderer. Then whenever init(GL gl) is called, the old TextureLoader can be disposed and a new one, which is only responsible for textures of the current GL, can be created.

[STRESS]

I like the second idea. It sounds much cleaner to me and you do not endup with strange interdepencies. I try to work around the issue for the moment to make sure I don't delete textures from my other contexts. Maybe by adding multiply ReferenceQueues for each GL context and store them in a seperate hashmap that would hopefully limit a potential memory leak in the worst case to some small java objects.

[steffen]

Just dont care about memleaks right now. It would be great if you can try to fix your problems this way. If it works I can do the ReferenceQueue stuff...

[gunn]

In the meantime, there may be a simple way to prevent the problems you're seeing with textures. The JOGL backend has an option to use shared GL contexts or not; by default, all JOGL viewers created in one Java VM share the same GL context. Sharing the same context means for example that display lists and texture id's are shared. To disable this feature pass the following flag to the Java VM:

Code: Select all

-Djreality.jogl.sharedContexts=false

It may be that the way that the hash tables are handled in Texture2DLoaderJOGL assumes that contexts are NOT shared. Unfortunately, there are very few applications here that test out this feature, that is, that run more than one JOGL viewer at one time. Please post anything you find out!

[STRESS]

Hi Gunn and Steffen,

I solved the problem for now by changing the code in Texture2DLoaderJOGL.java by adding a ReferenceQueue Hasmap for each GL context

Code: Select all

private static WeakHashMap<GL, ReferenceQueue<ImageData>> refQueues = new WeakHashMap<GL,ReferenceQueue<ImageData>>(); 

and then get the corresponding referenceQueue for the current gl context and dispose the GL textures

I know that this will introduce a potential GL memleak when the gl context disappears and the GL textures aren't getting disposed in this case. Not sure how bad that actually is, since I guess the driver should be able to handle this internally when the context gets closed.

[steffen]

Not sure how bad that actually is, since I guess the driver should be able to handle this internally when the context gets closed.

That would be really good to know... How can we figure that out?

[STRESS]

Well the only way to be 100% sure is to monitor the graphics card memory. Or maybe have a look with NV PerfHUD and ATI's equivalent performance monitor program. I haven't had a look at these for a very long time.

Unforuntately different platforms might show different behaviours.

[gunn]

This may be naive, but I'm nost sure how seriously we should take a GL memory leak. From my experience working with our jReality "mars demo" that loads lots of textures -- much more than the graphics card can hold -- it doesn't seem to matter if I unload the textures properly (i.e., delete them) or not. The oldest (i.e., those not referenced by the running program) appear to be simply overwritten by the GL memory manager. This is fine, since at any time I never have any more textures active in the scene graph than can fit on the graphics card. I do in fact now delete textures which are no longer needed, but there is an option NOT to do so, and the program still runs fine.

So, given this anecdotal evidence, I would be interested in evidence to the contrary, that is, implying that the GL memory manager runs of graphics memory rather than overwriting older textures.

Or perhaps I've misunderstood the question?

[STRESS]

I don't think it's that naive. And you're probably right since display drivers do a lot of internal memory jiggling (moving textures from internal GPU memory to PCI-Express/AGP memory space and even further out especially D3D10 generation cards need to have a full virtual memory manager) so I am pretty sure they keep track on these things (but you're never sure) and in OpenGL until very recent I think you had no control over it at all.
In Direct3D9 and 10 you are able to specify some hints but still drivers tend to ignore them very often. But GPU memory management is one of the biggest black box magic mysteries.

It's an interesting question and If I had enough time on my hands I would be keen to investigate this. Unfortunately I don't at the moment

For the moment personaly I don't see it as a big problem in my context.