Pan and Swipe Release #32

sidesixmedia · 2013-01-02T23:25:43Z

Hi fljot,

Thanks to your help in Issue 18, we have both Pan and Swipe gestures recognized now! However, we still can't accomplish something we see commonly among (ie.) photo viewer applications on Android and iOS:

PAN to slide an object back and forth as fast as the user moves their touch (working)
Allow for a SWIPE gesture anytime during the PAN gesture (partially working)
The SWIPE gesture can only occur if the user releases their touch from the device, otherwise the PAN continues to occur (not working)

Since the GesTouch SWIPE doesn't consider touch points, is their a way to accomplish using native GesTouch gestures or will we have to perform our own swipe recognition within the PAN CHANGED event? (For example, checking for a minimum velocity and listening for a TOUCH END event).

Thank you very much!

fljot · 2013-01-03T00:35:10Z

No swipe gesture is used in touch scrolling with snapping (paging). It's just pan + velocity and offsets. In iOS.. and pretty much sure in Android (that's a mess).

Are you really doing something better than https://github.com/fljot/TouchScrolling/blob/features/decoupled-architecture/src/com/inreflected/ui/touchScroll/TouchScrollModel.as (NB! not finished) ?

sidesixmedia · 2013-01-03T02:44:25Z

Ah, that's what I was starting to think. We'll check out the TouchScrollModel next! We're still having trouble loading your examples folders into Flash Builder. What project type is recommended: Flex Mobile? Actionscript Mobile?

Thanks, fljot. Keep up the great work!

sidesixmedia · 2013-01-04T02:42:20Z

While working on velocity calculations we're noticing that pan.offsetX and pan.offsetY are returning 0 on every other
GESTURE_CHANGED events. You can see what I mean from the trace output in our onPan() method:

offset: 0, 0
offset: 3, 3
offset: 0, 0
offset: 1, 0
offset: 0, 0
offset: 4, 4
offset: 0, 0
offset: 2, 0
offset: 0, 0
offset: 0, 1
offset: 0, 0
offset: 0, 2
offset: 0, 0

Is this the intended behavior? We're still working from your "Gestouch-slop-hotfix" branch.

fljot · 2013-01-04T14:09:42Z

No, this is definitely not intended behavior. Offset should always have some "length", otherwise it's not really a "change". I encourage you to investigate it =) Are you sure this event handler is for single gesture only and you are actually getting the offset from that gesture?

sidesixmedia · 2013-01-04T15:28:32Z

Yes, it's very basic and shouldn't have interference from anything else. We even created a test in the root of our Starling project and removed any content besides the stage:

Main Class Initialization

Gestouch.inputAdapter ||= new NativeInputAdapter(stage); 
Gestouch.addDisplayListAdapter(DisplayObject, new StarlingDisplayListAdapter());
Gestouch.addTouchHitTester(new StarlingTouchHitTester(star), -1);

Starling "Game" class

var pan:PanGesture = new PanGesture(stage);
pan.slop = 5;
pan.addEventListener(GestureEvent.GESTURE_CHANGED, onPan);

protected function onPan(e:GestureEvent):void {

        trace(pan.offsetX + ", " + pan.offsetY); // 0, 0
}

We see the same result using the 0.4.3 SWC as well as the 'Gestouch-slop-hotfix' branch. If the PanGesture is designed to return decimals, we're only getting INTs. I'm wondering if something is rounding or zeroing the offsets out.

fljot · 2013-01-04T15:40:34Z

It's only one place where setState(GestureState.CHANGED) is used in PanGesture, so I think you should trace the sh*t out of there.
Random questions:
Does pan.location actually changes every time?
One touch on the screen only?

sidesixmedia · 2013-01-04T15:54:51Z

pan.location SHOULD change everytime...we're touching an and object and then dragging it around in a circle as smoothly as possible. Some zeros are definitely natural, but pan is returning them literally every other cycle.

There is only one touch, one gesture listener, one gesture of any kind (hence why we removed our custom Starling code just to be sure).

We've got traces throughout PanGesture.as and Gesture.as. Here's a tracelog from our circular drag motion:

Gesture.as touchLocation: (x=420, y=367) centralPoint: (x=420, y=367)
_offsetX: -9 offsetY: 8
Gesture.as touchLocation: (x=420, y=367) centralPoint: (x=420, y=367)
_offsetX: 0 offsetY: 0
Gesture.as touchLocation: (x=418, y=371) centralPoint: (x=418, y=371)
_offsetX: -2 offsetY: 4
Gesture.as touchLocation: (x=418, y=371) centralPoint: (x=418, y=371)
_offsetX: 0 offsetY: 0
Gesture.as touchLocation: (x=418, y=374) centralPoint: (x=418, y=374)
_offsetX: 0 offsetY: 3
Gesture.as touchLocation: (x=418, y=374) centralPoint: (x=418, y=374)
_offsetX: 0 offsetY: 0
Gesture.as touchLocation: (x=418, y=378) centralPoint: (x=418, y=378)
_offsetX: 0 offsetY: 4
Gesture.as touchLocation: (x=418, y=378) centralPoint: (x=418, y=378)
_offsetX: 0 offsetY: 0
Gesture.as touchLocation: (x=418, y=379) centralPoint: (x=418, y=379)
_offsetX: 0 offsetY: 1
Gesture.as touchLocation: (x=418, y=379) centralPoint: (x=418, y=379)
_offsetX: 0 offsetY: 0

Obviously, the offsets are 0 because touchLocation and centralPoint are the same, but I'm trying to figure out what is happening to the prevLocationX and prevLocationY values because, as you said, they have to be different during a CHANGE event.

sidesixmedia · 2013-01-04T16:05:00Z

In the PanGesture.as onTouchMove() the updateLocation() call near line 165 returns the same value for _location so the offsets are calculated as 0. I can't notice anything immediately wrong with how the methods work, but maybe the values are being updated before the difference calculation occurs?

fljot · 2013-01-04T16:17:31Z

Like if touchMove(...) is executed twice per actual movement... Are touch.time and touch.location also the same in touchMove(...)?

sidesixmedia · 2013-01-04T16:33:04Z

Wow, maybe so. Some of the cycles do have the same time and it seems to correlate to when the offsets are 0:

onTouchMove: 382, 473 location: (x=366, y=473) touch.time: 2261 touch location: (x=366, y=473)
_offsetX: -16 offsetY: 0

onTouchMove: 366, 473 location: (x=366, y=473) touch.time: 2261 touch location: (x=366, y=473)
_offsetX: 0 offsetY: 0

onTouchMove: 366, 473 location: (x=357, y=474) touch.time: 2278 touch location: (x=357, y=474)
_offsetX: -9 offsetY: 1

onTouchMove: 357, 474 location: (x=357, y=474) touch.time: 2278 touch location: (x=357, y=474)
_offsetX: 0 offsetY: 0

onTouchMove: 357, 474 location: (x=354, y=475) touch.time: 2294 touch location: (x=354, y=475)
_offsetX: -3 offsetY: 1

onTouchMove: 354, 475 location: (x=354, y=475) touch.time: 2294 touch location: (x=354, y=475)
_offsetX: 0 offsetY: 0

onTouchMove: 354, 475 location: (x=352, y=476) touch.time: 2311 touch location: (x=352, y=476)
_offsetX: -2 offsetY: 1

onTouchMove: 352, 476 location: (x=352, y=476) touch.time: 2311 touch location: (x=352, y=476)
_offsetX: 0 offsetY: 0

fljot · 2013-01-04T16:37:52Z

In GesturesManager#onTouchMove(...) add some traces before and after the cycle to see if it actually makes one or two calls on gesture (that would be weird and very surprising!).

sidesixmedia · 2013-01-04T16:47:36Z

They have the same time stamps, but I'm not sure if that signifies a repetitious call:

GestureManager.as onTouchMove Touch [id: 0, location: (x=396, y=323), ...] time: 2877
onTouchMove: 400, 328 location: (x=396, y=323) touch.time: 2877 touch location: (x=396, y=323)
_offsetX: -4 offsetY: -5

GestureManager.as onTouchMove Touch [id: 0, location: (x=396, y=323), ...] time: 2878
onTouchMove: 396, 323 location: (x=396, y=323) touch.time: 2878 touch location: (x=396, y=323)
_offsetX: 0 offsetY: 0

GestureManager.as onTouchMove Touch [id: 0, location: (x=386, y=315), ...] time: 2894
onTouchMove: 396, 323 location: (x=386, y=315) touch.time: 2894 touch location: (x=386, y=315)
_offsetX: -10 offsetY: -8

GestureManager.as onTouchMove Touch [id: 0, location: (x=386, y=315), ...] time: 2894
onTouchMove: 386, 315 location: (x=386, y=315) touch.time: 2894 touch location: (x=386, y=315)
_offsetX: 0 offsetY: 0

GestureManager.as onTouchMove Touch [id: 0, location: (x=301, y=292), ...] time: 2911
onTouchMove: 386, 315 location: (x=301, y=292) touch.time: 2911 touch location: (x=301, y=292)
_offsetX: -85 offsetY: -23

GestureManager.as onTouchMove Touch [id: 0, location: (x=301, y=292), ...] time: 2911
onTouchMove: 301, 292 location: (x=301, y=292) touch.time: 2911 touch location: (x=301, y=292)
_offsetX: 0 offsetY: 0

GestureManager.as onTouchMove Touch [id: 0, location: (x=291, y=292), ...] time: 2927
onTouchMove: 301, 292 location: (x=291, y=292) touch.time: 2927 touch location: (x=291, y=292)
_offsetX: -10 offsetY: 0

GestureManager.as onTouchMove Touch [id: 0, location: (x=291, y=292), ...] time: 2927
onTouchMove: 291, 292 location: (x=291, y=292) touch.time: 2927 touch location: (x=291, y=292)
_offsetX: 0 offsetY: 0

Here is the GestureManager.as with trace:

gestouch_internal function onTouchMove(touch:Touch):void
        {
            var gesturesForTouch:Vector.<Gesture> = _gesturesForTouchMap[touch] as Vector.<Gesture>;
            var gesture:Gesture;
            var i:uint = gesturesForTouch.length;
            while (i-- > 0)
            {
                gesture = gesturesForTouch[i];

                if (!_dirtyGesturesMap[gesture] && gesture.isTrackingTouch(touch.id))
                {
                    trace("GestureManager.as onTouchMove "+touch+" time: " +touch.time);
                    gesture.touchMoveHandler(touch);
                }
                else
                {
                    // gesture is no more interested in this touch (e.g. ignoreTouch was called)
                    gesturesForTouch.splice(i, 1);
                }
            }
        }

sidesixmedia · 2013-01-04T17:29:20Z

I hope this is helpful. We don't want to get too deep and try debugging your work because we'd probably do more harm than good =)

fljot · 2013-01-04T18:32:17Z

No, you got me wrong. Trace before while and after while, this way we can see if gesture call is triggered twice per cycle (which should not happen normally).

sidesixmedia · 2013-01-04T18:40:07Z

Got it. Is this what you're looking for? There are still duplicates on every other call (signified between the trace linebreaks I added):

Before While 2705
After While 2705

Before While 2707
After While 2707

Before While 2722
After While 2722

Before While 2738
After While 2738

Before While 2739
After While 2739

Before While 2772
After While 2772

Before While 2788
After While 2788

Before While 2789
After While 2789

Before While 2805
After While 2805

gestouch_internal function onTouchMove(touch:Touch):void
{
    var gesturesForTouch:Vector.<Gesture> = _gesturesForTouchMap[touch] as Vector.<Gesture>;
    var gesture:Gesture;
    var i:uint = gesturesForTouch.length;
    trace("Before While "+touch.time);
    while (i-- > 0)
    {
        gesture = gesturesForTouch[i];

        if (!_dirtyGesturesMap[gesture] && gesture.isTrackingTouch(touch.id))
        {           
            gesture.touchMoveHandler(touch);
        }
        else
           {
            // gesture is no more interested in this touch (e.g. ignoreTouch was called)
            gesturesForTouch.splice(i, 1);
        }
    }
    trace("After While "+touch.time);
    trace("");
}

fljot · 2013-01-04T20:13:52Z

Noooo =))) keep the traces in gesture or handler also) this way we can see if theres sequence like "before, handler, handler, after" — there's bug in manager. If it's "before, handler, after" — manager is fine and dammit wtf.

sidesixmedia · 2013-01-04T20:20:51Z

I see. Added traces back to the PanGesture.as onTouchMove(). That appears to only be called once =)

Before While 1141
PanGesture onTouchMove: 332, 299 location: (x=332, y=299) touch.time: 1141 touch location: (x=332, y=299)
_offsetX: 0 offsetY: 0
After While 1141

Before While 1157
PanGesture onTouchMove: 332, 299 location: (x=328, y=301) touch.time: 1157 touch location: (x=328, y=301)
_offsetX: -4 offsetY: 2
After While 1157

Before While 1157
PanGesture onTouchMove: 328, 301 location: (x=328, y=301) touch.time: 1157 touch location: (x=328, y=301)
_offsetX: 0 offsetY: 0
After While 1157

Before While 1175
PanGesture onTouchMove: 328, 301 location: (x=314, y=309) touch.time: 1175 touch location: (x=314, y=309)
_offsetX: -14 offsetY: 8
After While 1175

Before While 1175
PanGesture onTouchMove: 314, 309 location: (x=314, y=309) touch.time: 1175 touch location: (x=314, y=309)
_offsetX: 0 offsetY: 0
After While 1175

Before While 1189
PanGesture onTouchMove: 314, 309 location: (x=312, y=312) touch.time: 1189 touch location: (x=312, y=312)
_offsetX: -2 offsetY: 3
After While 1189

Before While 1189
PanGesture onTouchMove: 312, 312 location: (x=312, y=312) touch.time: 1189 touch location: (x=312, y=312)
_offsetX: 0 offsetY: 0
After While 1189

Before While 1206
PanGesture onTouchMove: 312, 312 location: (x=312, y=315) touch.time: 1206 touch location: (x=312, y=315)
_offsetX: 0 offsetY: 3
After While 1206

Before While 1206
PanGesture onTouchMove: 312, 315 location: (x=312, y=315) touch.time: 1206 touch location: (x=312, y=315)
_offsetX: 0 offsetY: 0
After While 1206

Relevant portion of PanGesture.as onTouchMove:

else if (state == GestureState.BEGAN || state == GestureState.CHANGED)
            {
                prevLocationX = _location.x;
                prevLocationY = _location.y;                
                updateLocation();
                trace("PanGesture onTouchMove: "+prevLocationX+", "+prevLocationY+ " location: " + _location +" touch.time: "+ touch.time + " touch location: " +touch.location);
                _offsetX = _location.x - prevLocationX;
                _offsetY = _location.y - prevLocationY;
                trace("_offsetX: " +_offsetX+" offsetY: "+_offsetY);
                setState(GestureState.CHANGED);
            }

fljot · 2013-01-06T17:17:20Z

Great. So I found out that native event TouchEvent.TOUCH_MOVE is dispatched even when it's locations is the same, but touch size has changed. So try this commit 4398712

sidesixmedia · 2013-01-06T18:30:41Z

Nice. We'll try this version asap and see how things go. Having the extra cycles really didn't cause problems, but fixing it will hopefully benefit performance.

fljot · 2013-01-06T18:37:48Z

Well actually I consider it as a bug since no actual move was happening. And other than conceptual confusion it also could lead to wrong velocity calculation.

fljot closed this as completed Feb 19, 2013

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pan and Swipe Release #32

Pan and Swipe Release #32

sidesixmedia commented Jan 2, 2013

fljot commented Jan 3, 2013

sidesixmedia commented Jan 3, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 6, 2013

sidesixmedia commented Jan 6, 2013

fljot commented Jan 6, 2013

Pan and Swipe Release #32

Pan and Swipe Release #32

Comments

sidesixmedia commented Jan 2, 2013

fljot commented Jan 3, 2013

sidesixmedia commented Jan 3, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 4, 2013

sidesixmedia commented Jan 4, 2013

fljot commented Jan 6, 2013

sidesixmedia commented Jan 6, 2013

fljot commented Jan 6, 2013