Hi Tom,
Thanks for the suggestion.
Our operational system is using VisAD release 20100224 (Wed Feb 24
09:48:08 CST 2010) and as I mentioned in the previous email the provided
sample code will demonstrate the bug on VisAD 20100224 (release) and the
20100418 (nightly).
I tested with your suggestion of setting the system property
visad.java3d.geometryByRef to false, although sadly it did not resolve
the issue.
For thoroughness, I specifically re-tested the following combinations:
-Dvisad.java3d.geometryByRef=true (default)
- VisAD 20100224 (release): still occurs
- VisAD 20100418 (nightly), still occurs
- VisAD 20100420 (nightly), still occurs
-Dvisad.java3d.geometryByRef=false
- VisAD 20100224 (release): still occurs
- VisAD 20100418 (nightly), still occurs
- VisAD 20100420 (nightly), still occurs
Sincerely,
Dr Jason Brownlee
Software Engineer
Australian Bureau of Meteorology
On 04/21/2010 01:07 AM, Tom Rink wrote:
Hi Jason,
Did you change to release 20100224 and notice the problem? What was
the last release which did not cause this problem in your operational
system?
Before the 20100224 release, but possibly after the release date of
the prior VisAD version in your system, we began passing computed
geometry to Java3D byReference so as to reduce memory use. We
try very hard not to make superfluous changes to VisAD core, but
memory use is a big issue for us here. We did notice that using
geometry byReference tweaked some bugs in a fairly specific set
of ATI graphics adapters when using Java3D.
I suggest you try this to help us isolate the problem:
-Dvisad.java3d.geometryByRef=false, it is true by default.
Tom
Jason Brownlee wrote:
Hi All, I believe I have found a display bug in VisAD.
This bug was observed in an operational system and through a process
of exploration and testing it has been distilled to a VisAD code
example (attached).
The bug was observed in code that programmatically removed old data
references then added new data references to a DisplayImplJ3D. The
bug is manifest by disappearance (from the screen) of the geometry of
one of the data references that was recently added.
The bug is intermittent, although occurs approximately 1/2 runs in
our operational system, and approximately 1/20 in the standalone code
example. The probability of occurrence appears to increase with the
increase in the amount of manipulation of the geometry being drawn
(fonts, line thickness, transforms, etc).
Analysis shows the geometry is still in the scene graph, and is live.
Minimizing, resizing, further add/remove data references, and forced
doAction on the display do not correct the bug. Major operations on
the display that force a full re-draw (switching virtual desktops on
Linux, zoom operation in our application) will cause the geometry to
be displayed again.
Further analysis shows that the bug is invariant to making the
remove/add data reference calls from the same and different threads.
The bug may be related to a race condition, but it is likely deeper
within the VisAd infrastructure (or even Java3D!?).
This bug was observed operationally on Linux machines (redhat), in
development (fedora12), and has been reproduced on a windows machine
(winXP). The bug occurs with both Sun Java 1.5, 1.6, and Open JDK
1.6. Java3D version 1.5.1 was used in all cases. The bug occurs with
VisAD release 20100224 (Wed Feb 24 09:48:08 CST 2010) and the nightly
build 20100418. I believe all test machines had multiple cores.
I have attached a sample program (bug.ReproduceVISADBug) that will
generate the bug (please add visad.jar to the lib directory). The
test program draws a line and some text, then removes/adds data
references, the result is either the normal case (line and text are
displayed) or the bug case (either text or line are not displayed). I
have included an ant script and target (run-many) that can be used to
launch the program 20 times, one of which is likely to show an
example of the bug. The attached archive also includes some
screenshots of the normal and bug cases experienced with the sample
application (for verification).
The sample code is intentionally lean and may use some bad practices,
although I believe that the bug is invariant. Nevertheless, I am wide
open to suggestions and critiques.
I've been climbing through VisAD without luck. Please let me know if
I can gather further evidence in order to help resolve this issue.
Sincerely,
Dr Jason Brownlee
Software Engineer
Australian Bureau of Meteorology
------------------------------------------------------------------------
_______________________________________________
visad mailing list
visad@xxxxxxxxxxxxxxxx
For list information, to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
