> I guess we now have to figure out why it is so important to make a copy > of the coordinates before they are returned... > > Mmmm... very, very strange...
Well, I am completely at a loss. I would appreciate it if one of you could verify my line of reasoning and observations to confirm the following: ------ - the variable screenPosition is private in Atom.java - there are no subclasses of Atom - screenPosition is set to a new Point3f() at object instantiation - the variable screenPosition is never set again (could/should be final) - screenPosition is side-effected by Matrix4d.transform(...) in Atom.transform(...) - Atom.transform(...) is the only place that modifies/sets screen-position. - Even if somebody *did* whack the values in this variable, they would be reset on the next call to transform ... because the Point3f is only used for output. ------ - the method atom.getScreenPosition() currently returns a copy of the variable screenPosition - every invocation of Atom.getScreenPosition() is followed by an immediate reference to .x, .y, or .z (grep getScreenPosition *.java | less) - every one of these is in an r-value (as opposed to l-value) context - therefore nothing can be modifying the copy of the screen position returned by Atom.getScreenPosition() - since the Point3f returned by Atom.getScreenPosition() is always used in a read-only context, there should be no reason not to return the "original" screenPosition object. ------ - the only possibility I can see for conflict is if Atom.transform(...) is called at the same time that someone is using the screenPosition object. - however, the only place that calls transform(...) is inside the ChemFrameRenderer.paint() method. - that thread is the same thread that is calling Atom.getScreenPosition() - the transform is applied before the Z sort and before the rendering. - therefore, there cannot be a thread synchronization issue - even if there was, it would be corrected (for that atom) on the next repaint, since screenPosition is used as output from Matrix4d.transform() ------ Now, in writing this the only thing that comes to mind is that possibly somehow the atom positions themselves or the transformationMatrix are getting whacked. That would account for the screen positions getting mapped to 0,0,0. If you can, please review and let me know what you think. (And if you don't review it then that is OK too ... it did me good to get it off of my chest). mth ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
