-
Bug
-
Resolution: Fixed
-
P2
-
8
These regressions were caused by RT-32600 (including follow on fixes) comprising revisions 4882, 4974, 5034. Hopefully the fix for this doesn't cause yet another regression :-).
There are two problems. The first is that the PDR gestures are completely broken. The reason appears to be due to the change in revision 4974. It is not obvious as to how this change was semantically different. I suspect we were getting lucky before this change. It used to be that we fired both mouse and touch events from the native side, whereas after this change, we fired the event only from the Java side, and did so synthetically. I'm still trying to understand, exactly, how this worked.
However what I did find was that if the primary button is not down for drag events, then the Scene code will consider the PDR gesture to have ended. One way or another, we must have been setting this before (although I can't yet see where). Once I set the primary button to be down (with modifiers + specifying the button), everything works.
The second problem was one of jitter. The events we get from the OS are not clean. Essentially, the touch events coming in are samples, and according to my tests. can have variance as great as +/- 3 pixels in any dimension. Because of this, even if my finger was stationary, the object being dragged would jiggle as it was told it was at 10px... no 12px... no 7px! Instead, we need a method for filtering out the noise. The simplest approach seems to work. I simply record the last x/y, and compare with the new x/y. If the new x/y is within +/- 3 pixels of the last one, I ignore it. Otherwise we go ahead and post (or update a previously posted event). This seems to completely smooth out the noise on my PI. However, it is likely this magic '3' number is system specific, and we may need a system variable to be able to tweak this.
There are two problems. The first is that the PDR gestures are completely broken. The reason appears to be due to the change in revision 4974. It is not obvious as to how this change was semantically different. I suspect we were getting lucky before this change. It used to be that we fired both mouse and touch events from the native side, whereas after this change, we fired the event only from the Java side, and did so synthetically. I'm still trying to understand, exactly, how this worked.
However what I did find was that if the primary button is not down for drag events, then the Scene code will consider the PDR gesture to have ended. One way or another, we must have been setting this before (although I can't yet see where). Once I set the primary button to be down (with modifiers + specifying the button), everything works.
The second problem was one of jitter. The events we get from the OS are not clean. Essentially, the touch events coming in are samples, and according to my tests. can have variance as great as +/- 3 pixels in any dimension. Because of this, even if my finger was stationary, the object being dragged would jiggle as it was told it was at 10px... no 12px... no 7px! Instead, we need a method for filtering out the noise. The simplest approach seems to work. I simply record the last x/y, and compare with the new x/y. If the new x/y is within +/- 3 pixels of the last one, I ignore it. Otherwise we go ahead and post (or update a previously posted event). This seems to completely smooth out the noise on my PI. However, it is likely this magic '3' number is system specific, and we may need a system variable to be able to tweak this.