Page 1 of 1

ToolSystem crash

Posted: Tue 17. Feb 2009, 05:12
by olaf
Since this is my first post here, let me first say that I sincerely enjoy working with jReality. Congratulations on creating a great visualization platform!

Now to the bug report: I work with multiple screens on Ubuntu 8.04. Whenever the mouse pointer leaves the current screen, an invalid mouse position seems to be generated. I've seen this with several programs, which dealt with problem with varying degrees of grace.

At any rate, the rotate tool - and possibly others - throws an exception which brings the whole tool system to a halt. With the latest release, I get the following stack trace:

Code: Select all

Exception in thread "jReality ToolSystem EventQueue" java.lang.IllegalStateException: NaN
	at de.jreality.math.P3.makeTranslationMatrix(P3.java:646)
	at de.jreality.math.P3.extractOrientationMatrix(P3.java:165)
	at de.jreality.tools.RotateTool.objToAvatar(RotateTool.java:172)
	at de.jreality.tools.RotateTool.perform(RotateTool.java:143)
	at de.jreality.toolsystem.ToolSystem.processToolSet(ToolSystem.java:510)
	at de.jreality.toolsystem.ToolSystem.processTriggerQueue(ToolSystem.java:421)
	at de.jreality.toolsystem.ToolSystem.processToolEvent(ToolSystem.java:308)
	at de.jreality.toolsystem.ToolEventQueue$1.run(ToolEventQueue.java:79)
	at java.lang.Thread.run(Unknown Source)
With the current svn sources, the behaviour is the same - the tool systems effectively freezes - but I don't see that stack trace anymore.

The dragging tool, by the way, does strange things when the cursor leaves the current screen, but recovers when it returns.

Posted: Tue 17. Feb 2009, 11:36
by gunn
Thanks for the kind words. :D

I've checked in a revised version of RotateTool (and DraggingTool also) which attempts to detect that there are "NaN's" in play and returns early from perform(). We might however be better off if we detect the bad mouse positions in the raw mouse device, since it probably tends to effect all tools. Will put on the TODO list.

Please post if there continue to be problems. If you're not using the svn repository then you will need to start, since we don't make binary releases every time we fix a bug.

Posted: Tue 17. Feb 2009, 14:58
by olaf
Thanks! That was quick.

With your fix, the toolsystem still gets into a strange state, but it doesn't crash anymore. After experimenting a bit, I came up with the following modification to RotateTool::perform(), which makes the object jump a bit when the mouse pointer leaves the screen, but at least allows me to keep using the toolsystem:

Code: Select all

  public void perform(ToolContext tc) {
    Matrix object2avatar = new Matrix((moveChildren ? tc.getRootToLocal():tc.getRootToToolComponent()).getInverseMatrix(null)); 
    if (Rn.isNan(object2avatar.getArray())) {
    	MatrixBuilder.euclidean().assignTo(comp); //added this (ODF)
    	return;
    }

Found a better fix

Posted: Wed 18. Feb 2009, 02:42
by olaf
Okay, I poked the source code a bit more and found a better solution.

The following modification to the end of RotateTool::perform() simply puts the rotation on hold until the mouse position leads to a correct transformation again:

Code: Select all

    if (!fixOrigin) result.multiplyOnRight(center.getInverse());
    if (Rn.isNan(result.getArray())) return; // this line added (ODF)
    comp.getTransformation().setMatrix(result.getArray());
  }

Posted: Wed 18. Feb 2009, 14:11
by gunn
I've made this change in the source repository here. If you do happen to have a chance to investigate a bit more what the nature of the "bad mouse coordinates" under Ubuntu is, please report it here. Then, we can add a check in the raw mouse device to detect that state rather than combatting it in the individual tools. Thanks.

Posted: Wed 18. Feb 2009, 15:22
by olaf
I installed a MouseMotionListener on the viewing component that prints the mouse position on each drag. When the mouse pointer leaves the screen, drag events with position (0, 0) are generated. No idea why that would be a problem. Let me know if there's anything else I should try.