Hey Dixie. Thank you for posting here and creating that sample stack. However, I think what I am trying to solve was misunderstood and I am trying my best to communicate it as clearly as possible.
It is not an issue of calculation, its an issue of Android processing time. The fact is that for moving large groups, it takes a while for the screen to redraw only the first few times. This creates a lag making it so the TOUCHMOVE AND the MOUSEMOVE handlers DONT EVEN EXECUTE. If they were running, then yes, your stack would be a possible solution.
I was able to figure out a solution however that works for now.... It was to move my velocity sampling lines of code to the beginning of the handler before the MoveTouch. That way I would get a single point as the touch started, (my code is set to not start scrolling until 10 pixels of movement), then it would come around a second time and give me a second point to calculate velocity (Much like your equation Dixie) before the screen would redraw causing the app to freeze momentarily. That was enough to get the sample I needed for the velocity of the group. I do not know if that is a permanent solution however, it did work on my Android Galaxy S3. I have yet to test it on slower devices.
The solution ended up looking like this:
Code: Select all
on TouchMove pID, pX, pY
if sScroll is not "true" then exit TouchMove
##Record Touch Timing
put line 2 of sTouchTimer into line 1 of sTouchTimer
put the millisecs & comma & pY into line 2 of sTouchTimer --Use the touch
MoveTouch ---The handler where I move my enormous scrolling group which takes 13 to 140 milliseconds depending on whether it is starting to move or not
pass TouchMove
end TouchMove
If that doesn't work, another way to get around it is to not redraw the screen until I can get a second sample point from the touchMove handler.
Such code like this would do the trick, but idk if it is necessary yet
Code: Select all
on TouchMove pID, pX, pY
if sScroll is not "true" then exit TouchMove
##Record Touch Timing
put line 2 of sTouchTimer into line 1 of sTouchTimer
put the millisecs & comma & pY into line 2 of sTouchTimer --Use the touch
if the number of lines in sTouchTimer < 2 then pass TouchMove --Let it come around again to get the second sampling point.
MoveTouch ---The handler where I move my enormous scrolling group which takes 13 to 140 milliseconds depending on whether it is starting to move or not
pass TouchMove
end TouchMove
Anyways, this took a rediculous amount of testing to figure out. Was one of those solutions that came to me while I was sleeping (Im weird, I dream about code. lol)
I hope this demonstrates a solution to all those in the future trying to figure out how to work with mobile processing times.
I am still curious as to why it is that during the first half second that the engine needs 5 times the amount of time to redraw the moving group...? Any ideas?
Cheers,
-Will
