Shaky TransformGesture about gestouch HOT 5 OPEN

@djankey

well I'd say that's due to sequential nature of delivering touch events in flash runtime (one touch event after another). So ur moving consists of small rotations mostly, because you receive one TouchEvent -> moves Touch -> delivers Touch to Gesture -> you rotate and move object a bit. Repeat.

I had idea of buffering touches in the core of the system and then delivering them into Gestures. (In JavaScript, for example, TouchEvent has not one, but array of touches, so runtimes does it for you.)
But I don't have time/motivation to do it.

What you can do to improve visuals:
In your view accumulate transformations from the gesture and apply them a bit later using any approach, for example:
stage.invalidate() + Event.RENDER approach (I'm sure you can google this invalidation approach)
or
delayed for Event.ENTER_FRAME approach.

Does it make sense to you?

from gestouch.

Thank you, it make sense.

I tried Event.RENDER and Event.ENTER_FRAME (and EXIT_FRAME) and results are approximately the same, no big difference.
When two fingers are closer to each other shakiness is worse...

from gestouch.

@djankey

You sure you did it right? Can you show your implementation?

Yeah, the closer fingers are – the bigger rotation angle after each finger movement.

Well if delay really doesn't give good result, then maybe you could look at this situation like so:
you want to ignore rotations (not apply them to the view) while you perform panning. What else distinguishes rotations while panning and more intended ones? While you pan they should be like +n, -n, +n, -n (more or less, you should log them while actually doing it). So if rotations from gesture are jumping to positive and negative values – looks like you don't want to apply them. If they're more consistent in their direction (e.g. rotations in N or more events all positive or negative) – that looks more like real rotation intent, so you need to apply some rotation to the view.

from gestouch.

This is code for ENTER_FRAME: http://pastebin.com/6tZRRJCb
Similar code is also for RENDER and invalidate...

I agree with +, - and continuous values... will try that.

from gestouch.

@djankey

hm if delay doesn't help, I means buffering in the core of the library also wouldn't do the trick.. I imagined that both fingers should dispatch touch events during one frame cycle, so if you apply accumulated transformations – it should be way better. But if you say it doesn't give nice result – I wonder how it actually happens.

If you could provide some log to see what actually happens (list of gesture responses with frame counter just for reference) – that might be useful, as input data. Apart from offsets and rotation maybe Gesture.location could be useful (center point between touches).

from gestouch.