887509 - [homescreen] swipe at the first touchmove event instead of waiting for the touchend event

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Improving HomeScreen stutter during scroll

Comment 1

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: Improving homescreen scroll

Normally, Homescreen starts panning at 1st touchmove event (http://mxr.mozilla.org/gaia/source/apps/homescreen/js/grid.js#277) and scrolls after getting touchend event (http://mxr.mozilla.org/gaia/source/apps/homescreen/js/grid.js#346). I changed homescreen to scroll for full page transition on 1st touchmove event. I added two threshold parameter for this ( velocity_fastswipe and fastswipe_distance) . velocity_fastswipe determines velocity of getting touchstart and touchmove event. fastswipe_distance determines distance travelled between touchstart and touchmove event. If these two exceeds certain threshold then homescreen starts fullpage transition on 1st touchmove event. it doesn't wait for touchend event. This solves delay between two paints (one comes from touchmove and another from touchend). I also delays additional paints at the end of scroll from here http://mxr.mozilla.org/gaia/source/apps/homescreen/js/grid.js#565 . It removes slight stutter at the end of scroll.

Comment 2

[Cristian Rodriguez (:crdlc)]

Please close it or bug 887509, are they duplicated?

Comment 3

[Cristian Rodriguez (:crdlc)]

please review the lint errors and conflicts

Comment 4

[Cristian Rodriguez (:crdlc)]

and the last thing, how does it improve the panning? Because you are nominating a patch that touches the core and IMHO it is working really good.

Comment 5

[Michael Vines [:m1] [:evilmachines]]

(In reply to Cristian Rodriguez de la Cruz (:crdlc) from comment #2)
> Please close it or bug 887509, are they duplicated?

What is "it"?

Comment 6

[Cristian Rodriguez (:crdlc)]

> What is "it"?

sorry, forget that, because in my inbox two different duplicated bugs were available due to

Summary: Improving HomeScreen stutter → Reducing HomeScreen stutter

Comment 7

[Cristian Rodriguez (:crdlc)]

Sorry it was my fault Michael

Comment 8

[Michael Vines [:m1] [:evilmachines]]

np!  ni? Tapas for comment 4 (I'm assuming comment 3 can be addressed in an updated PR).

Comment 9

[David Flanagan [:djf]]

Tapas,

1) three reviewers is too many. It doesn't make sense for all three of us to look at this patch, at least not to start. Cristian is probably the right reviewer for this. I'm going to cancel the r? for myself.

2) You haven't really explained what the actual bug is that this patch fixes and why it is serious enough to warrant nomination for Leo. I agree with Cristian that this is code that we would not want to modify lightly.

3) In your description you say that you start the page transition without waiting for the touchend event. This means that the screen no longer follows the user's finger, which seems like a pretty fundamental feature of touchscreen panning. If I'm understanding you correctly, there is no way we could land that without approval from our UX team.

4) If you really are basing your decision to pan or not to pan based on the very first touchmove event after touchstart, that seems like it would be hardware dependent.... Devices that send out touchmove events more frequently or less frequently might have homescreens that feel very different. I'd worry that some would pan much too easily.

Comment 10

[David Flanagan [:djf]]

Comment on attachment 768054 [details]
Improving homescreen scroll

I haven't looked at the code, but my meta-comments on this bugs are above. Cancelling the r? for myself, since Cristian is more qualified than I am, and because I'll be away on vacation soon and won't be able to see this bug through.

Comment 11

[Andrew Overholt [:overholt]]

While improving the homescreen scrolling is a great thing to do, this isn't something that triage decided could be taken for 1.1 at this time since it's not fixing a regression or a scoped 1.1 feature.

Comment 12

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #8)
> np!  ni? Tapas for comment 4 (I'm assuming comment 3 can be addressed in an
> updated PR).

I will upload a new PR here.

Comment 13

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to David Flanagan [:djf] from comment #9)
> Tapas,
> 
> 1) three reviewers is too many. It doesn't make sense for all three of us to
> look at this patch, at least not to start. Cristian is probably the right
> reviewer for this. I'm going to cancel the r? for myself.
> 
Sry, I will do it next time onwards. 
> 2) You haven't really explained what the actual bug is that this patch fixes
> and why it is serious enough to warrant nomination for Leo. I agree with
> Cristian that this is code that we would not want to modify lightly.
> 
> 3) In your description you say that you start the page transition without
> waiting for the touchend event. This means that the screen no longer follows
> the user's finger, which seems like a pretty fundamental feature of
> touchscreen panning. If I'm understanding you correctly, there is no way we
> could land that without approval from our UX team.
> 
Currently, screen starts panning just after getting 1st touchmove event. But it doesn't do full page transition. It does full page transition only after touchend event.  I added some touch sensitivity parameters (VELOCITY_SCROLL, DISTANCE_SCROLL, commented in code) to make a full page transition in 1st touchmove event. If both VELOCITY_SCROLL & DISTANCE_SCROLL are very low then homescreen pan simply works like old method i.e it waits for touchend event. But if it exceeds certain threshold then it makes a full page transition in 1st touchmove event without waiting for touchend event. This is required because there is a delay between 1st touchmove and touchend : ~200ms (it can vary from device to device, for TCL device it is ~200 ms. This delay happens becuase touchmove starts a long paint immediately) . If a user decides to do full page transition by making faster touchmove then why should we wait for touchend event to start scrolling ? Doesn't it delay whole scrolling process ? Please suggest. 


> 4) If you really are basing your decision to pan or not to pan based on the
> very first touchmove event after touchstart, that seems like it would be
> hardware dependent.... Devices that send out touchmove events more
> frequently or less frequently might have homescreens that feel very
> different. I'd worry that some would pan much too easily.
For each touch, i saw :
1) one touchstart event
2) single or multiple touchmove event
3) one touchend event

I think, this sequence should be same for all device. My patch is making a scroll decision on 1st touchmove event and ignore all touchevents till we get next touchstart event again . So it shouldn't matter whether device is sending touchmove events more frequently or not. But for each device, we need to play with 3 parameters :

1) VELOCITY_SCROLL : used for scroll detection in 1st touchmove event
2) DISTANCE_SCROLL : used for scroll detection in 1st touchmove event
3) PAGE_DELAY : used to delay last paint after getting CSS transitionend event. It helps to delay last paint to make end of scroll smooth. It may vary from device to device. 

If we set VELOCITY_SCROLL = 99999,DISTANCE_SCROLL=99999 and  PAGE_DELAY=0 then this patch will behave as if it is not present on device i.e it will follow old method of panning on any device. We need to tune up and fixed these parameters for each device . Currently, I optimized these parameters for TCL buri device. 

@mvikram can you please suggest here .

Comment 14

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Tapas Kumar Kundu from comment #12)
> (In reply to Michael Vines [:m1] [:evilmachines] from comment #8)
> > np!  ni? Tapas for comment 4 (I'm assuming comment 3 can be addressed in an
> > updated PR).
> 
> I will upload a new PR here.

I updated PR to fix lint errors and conflicts.

Comment 15

[Cristian Rodriguez (:crdlc)]

It says: We can’t automatically merge this pull request.

Comment 16

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: Improving homescreen scroll

Comment 17

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: Improving homescreen scroll

Comment 18

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: Improving homescreen scroll

Comment 19

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Cristian Rodriguez de la Cruz (:crdlc) from comment #15)
> It says: We can’t automatically merge this pull request.

Can you please check again. I uploaded new PR .

Comment 20

[Cristian Rodriguez (:crdlc)]

Please review:

1) Lint errors [1] and..
2) Unit tests, it seems broken (grid_test.js)

[1]

----- FILE  :  /home/travis/build/mozilla-b2g/gaia/apps/homescreen/js/grid.js -----
Line 50, E:0002: Missing space before "="
Line 50, E:0002: Missing space after "="
Line 51, E:0002: Missing space before "="
Line 51, E:0002: Missing space after "="
Line 52, E:0002: Missing space before "="
Line 52, E:0002: Missing space after "="
Line 213, E:0002: Missing space before "-"
Line 213, E:0002: Missing space after "-"
Line 234, E:0110: Line too long (83 characters).
Line 235, E:0002: Missing space before "("
Line 235, E:0002: Missing space after ">"
Line 242, E:0002: Missing space after ","
Line 374, E:0002: Missing space before "="
Line 374, E:0002: Missing space after "="
Line 375, E:0002: Missing space before "="
Line 375, E:0002: Missing space after "="
Line 376, E:0002: Missing space before "="
Line 376, E:0002: Missing space after "="
Line 423, E:0002: Missing space after ">"
Line 438, E:0002: Missing space after ","
Line 438, E:0002: Missing space after ","
Line 575, E:0002: Missing space before "("
Line 577, E:0110: Line too long (81 characters).
Line 578, E:0110: Line too long (81 characters).
Line 580, E:0110: Line too long (99 characters).
Line 583, E:0110: Line too long (81 characters).
Line 603, E:0002: Missing space before "("
Line 608, E:0110: Line too long (95 characters).
Found 28 errors, including 0 new errors, in 1 files (835 files OK).

Comment 21

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: Reducing HomeScreen Stutter

Please set VELOCITY_SCROLL = 0.04 if you test this patch on TCL device and VELOCITY_SCROLL = 0.019 if you test this patch on 8226 device at line #3. I corrected lint errors. Please let me know if I need to any more changes. 

Sorry for the delay.

Comment 22

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

This patch works best on 1.1. It also reduces stutter on master branch.

Comment 23

[Michael Vines [:m1] [:evilmachines]]

(In reply to Tapas Kumar Kundu from comment #21)
> Please set VELOCITY_SCROLL = 0.04 if you test this patch on TCL device and
> VELOCITY_SCROLL = 0.019 if you test this patch on 8226 device at line #3.

Can we compute VELOCITY_SCROLL at runtime based on the device screen size?  First device mentioned is HVGA and the other is more like WVGA.

Comment 24

[Cristian Rodriguez (:crdlc)]

There is still lint erros and the unit testing is broken. Please review it, thanks

----- FILE  :  /home/travis/build/mozilla-b2g/gaia/apps/homescreen/js/grid.js -----
Line 235, E:0120: Binary operator should go on previous line "/"

Comment 25

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Cristian Rodriguez de la Cruz (:crdlc) from comment #24)
> There is still lint erros and the unit testing is broken. Please review it,
> thanks
> 
> ----- FILE  : 
> /home/travis/build/mozilla-b2g/gaia/apps/homescreen/js/grid.js -----
> Line 235, E:0120: Binary operator should go on previous line "/"

I run gjslint and fixed it now. Can you please check it now . 

Thanks

Comment 26

[Cristian Rodriguez (:crdlc)]

Please check the tests before asking review because they are broken

https://travis-ci.org/mozilla-b2g/gaia/builds/8775039

Thanks a lot

Comment 27

[Cristian Rodriguez (:crdlc)]

Comment on attachment 771493 [details]
Reducing HomeScreen Stutter

Please Julien, could you take a look to it and give us feedback about this patch? Thanks a lot

Comment 28

[Cristian Rodriguez (:crdlc)]

Please Tapas, I added several comments on Github about your patch. If you have doubts please ask me. Thanks for you work!

Comment 29

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Cristian Rodriguez de la Cruz (:crdlc) from comment #28)
> Please Tapas, I added several comments on Github about your patch. If you
> have doubts please ask me. Thanks for you work!

I will update a patch with your suggestion soon . Thanks .

Comment 30

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #23)
> (In reply to Tapas Kumar Kundu from comment #21)
> > Please set VELOCITY_SCROLL = 0.04 if you test this patch on TCL device and
> > VELOCITY_SCROLL = 0.019 if you test this patch on 8226 device at line #3.
> 
> Can we compute VELOCITY_SCROLL at runtime based on the device screen size? 
> First device mentioned is HVGA and the other is more like WVGA.

VELOCITY_SCROLL = (distance travelled between touchstart and touchmove event ) / ( timestamp of touchmove event - timestamp of touchstart event) 

It seems to me that it is device specific .

Comment 31

[Michael Vines [:m1] [:evilmachines]]

(In reply to Tapas Kumar Kundu from comment #30)
> VELOCITY_SCROLL = (distance travelled between touchstart and touchmove event
> ) / ( timestamp of touchmove event - timestamp of touchstart event) 
> 
> It seems to me that it is device specific .

Could this not be multiplied by some number derived from the current device display dimensions to compute a VELOCITY_SCROLL value that works good enough for devices HVGA, WVGA, etc sized devices?

Comment 32

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #31)
> (In reply to Tapas Kumar Kundu from comment #30)
> > VELOCITY_SCROLL = (distance travelled between touchstart and touchmove event
> > ) / ( timestamp of touchmove event - timestamp of touchstart event) 
> > 
> > It seems to me that it is device specific .
> 
> Could this not be multiplied by some number derived from the current device
> display dimensions to compute a VELOCITY_SCROLL value that works good enough
> for devices HVGA, WVGA, etc sized devices?

It would be great if it is possible to do so. I have not tried to do it so far. But it seems to me that this VELOCITY_SCROLL is very sensitive to hardware touch driver. I will test on two HVGA device and update results here soon.

Comment 33

[Julien Wajsberg [:julienw]]

Just tested on Unagi and I don't really like the feeling, the panning happens too fast. I tried with both 0.019 and 0.04.

At the very last we'll need an UX stamp before doing this.

Comment 34

[Julien Wajsberg [:julienw]]

Comment on attachment 771493 [details]
Reducing HomeScreen Stutter

I haven't looked at everything but I like the idea.

I left comments on the github pull request. But basically we need to be careful with the default numbers (I'd like to find numbers or heuristics that work the same everywhere), you need to split the patch between the stutter issue and the panning-asap issue

and I'd like to see this implemented as part of the panningResolver. I know it's always easier do add a "if" and work besides some code that you don't want to understand, but it's not maintenable.

Thanks, I'd really want to see this pushed forward !

Comment 35

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Julien Wajsberg [:julienw] from comment #34)
> Comment on attachment 771493 [details]
> Reducing HomeScreen Stutter
> 
> I haven't looked at everything but I like the idea.
> 
> I left comments on the github pull request. But basically we need to be
> careful with the default numbers (I'd like to find numbers or heuristics
> that work the same everywhere), you need to split the patch between the
> stutter issue and the panning-asap issue
> 
> and I'd like to see this implemented as part of the panningResolver. I know
> it's always easier do add a "if" and work besides some code that you don't
> want to understand, but it's not maintenable.
> 
> Thanks, I'd really want to see this pushed forward !

I saw your comments in github and I will upload a patch with your suggestions !! . Sorry for the delay .

Thanks

Comment 36

[Julien Wajsberg [:julienw]]

I just want to say that I tried again the current homescreen, and we actually already pan before touchend if the user pans fast enough. So maybe new code is not so necessary, and we only need to fine tune some values ?

Comment 37

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Julien Wajsberg [:julienw] (PTO 15th -> 28th July) from comment #36)
> I just want to say that I tried again the current homescreen, and we
> actually already pan before touchend if the user pans fast enough. So maybe
> new code is not so necessary, and we only need to fine tune some values ?

I agree that we are panning with 1st touchmove. But it doesn't pan fulling in 1st touchmove event (we cannot go to next page with 1st touchmove event) . We are doing full pan in two steps. 1st step : 1) pan partially as soon as we get 1st touch move event 2) Complete pan with touchend. 

This methods works perfectly well for some cases like user wants to pan slowly or user doesn't want to move next page in 1st pan . 


But for faster touchmove, we don't want to show any delay (30ms to 200ms delay) between (1) and (2) . Otherwise, user sees 30ms to 200ms delay during panning.

Comment 38

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Tapas Kumar Kundu from comment #37)
> (In reply to Julien Wajsberg [:julienw] (PTO 15th -> 28th July) from comment
> #36)
> > I just want to say that I tried again the current homescreen, and we
> > actually already pan before touchend if the user pans fast enough. So maybe
> > new code is not so necessary, and we only need to fine tune some values ?
> 
> I agree that we are panning with 1st touchmove. But it doesn't pan fulling
> in 1st touchmove event (we cannot go to next page with 1st touchmove event)
> . We are doing full pan in two steps. 1st step : 1) pan partially as soon as
> we get 1st touch move event 2) Complete pan with touchend. 
> 
> This methods works perfectly well for some cases like user wants to pan
> slowly or user doesn't want to move next page in 1st pan . 
> 
> 
> But for faster touchmove, we don't want to show any delay (30ms to 200ms
> delay) between (1) and (2) . Otherwise, user sees 30ms to 200ms delay during
> panning.

This can be confirmed with HIGH FPS camera .

Comment 39

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: Reducing HomeScreen Stutter

Comment 40

[Cristian Rodriguez (:crdlc)]

Hi Tapas,

   You have some comments about code and implementation on Github, please read them when you can. Although the most important thing is that there are some functionality broken:

* If I move my finger very slow, the homescreen will always change the current page at least with my Unagi.

* Sometimes the active/focus of the icons is not removed, see removeActive function on touchend event part.

   And the last strange behavior IMHO is when the early swipe is performed, I have to release my finger, because if I move it, the page is frozen.

Thanks a lot

Comment 41

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Cristian Rodriguez de la Cruz (:crdlc) from comment #40)
> Hi Tapas,
> 
>    You have some comments about code and implementation on Github, please
> read them when you can. Although the most important thing is that there are
> some functionality broken:
> 
> * If I move my finger very slow, the homescreen will always change the
> current page at least with my Unagi.
> 

That is expected behaviour from this patch. This patch uses following condition to determine full page transition:

if (Math.abs(currentX - startX) > swipeDistance &&
    Math.abs(panningResolver.getVelocity()) > swipeVelocity)

Right now, swipeDistance is fixed to 1 pixel and swipeVelocity is fixed to 0.019 in application-data.js . 
You may need to readjust these for testing behaviour. Or we can set a larger constant value here for all devices. 

There is a trade off for these constant values. 

Smaller constant values means that it will trigger full page transition always. You have to move your finger really very slow to pan and go between two pages.

Larger constant values may not do full page transition always even if user's intention is full page transition.

If user's intention is to do full page transition and larger constant fails to trigger full page transition then homescreen pan will do exactly as it is doing currently (i.e. it will show 30ms to 200ms delay during panning . It can be confirmed with high FPS camera).

Please suggest.


> * Sometimes the active/focus of the icons is not removed, see removeActive
> function on touchend event part.
> 
It seems to me that it can be fixed. I will check and update here.

>    And the last strange behavior IMHO is when the early swipe is performed,
> I have to release my finger, because if I move it, the page is frozen.
> 
It seems to me that it can be fixed. I will check and update here.
> Thanks a lot


I will address your comments in github. 

Thanks
Tapas

Comment 42

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: Reducing HomeScreen Stutter

Please review it.

Comment 43

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Hi Cristian,

Could you please clear my doubts in github of this commit ? 

Thanks a lot.

Comment 44

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Hi Cristian,

I updated PR with your suggestions in github. Please review it . Thanks a lot .

Comment 45

[Cristian Rodriguez (:crdlc)]

Hi Tapas, the indentation is still broken in the new big block, thanks

Comment 46

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

updated with indentation fixes. Thanks

Comment 47

[Cristian Rodriguez (:crdlc)]

Comment on attachment 778994 [details]
Reducing HomeScreen Stutter

My apologies for changing the reviewer but I start my holidays in a couple of hours and I think that Julien is the best to do this. Please Julien, if you don't want to do the review, maybe Vivien could be the best as well.

Thanks to yoy and sorry

Comment 48

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Hi Julien,

PanningResolver() contains only panning threshold functions (like getVelocity() etc) and actual pan functions like RemovePanHandler() and Pan() is inside handleEvent().

Early swipe also do same work like RemovePanHandler()and Pan(). So it seems to me that it is more suitable to put it inside handleEvent(). 

However, I can put all early swipe code inside PanningResolver() if you want me to do so. 


Please review github changes and suggest.

Comment 49

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Changing review request from [e-mail] to [e-mail]

Comment 50

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Hi Cristian/julein,

Could you please review this. Thanks a lot.

Comment 51

[Julien Wajsberg [:julienw]]

reviewing this now, sorry for the delay.

Comment 52

[Julien Wajsberg [:julienw]]

Comment on attachment 778994 [details]
Reducing HomeScreen Stutter

review finished

still a lot of questions, I really want to see this more integrated with the existing code, even if I see you already made some effort using the panning resolver.

Thanks, and sorry again for the delay. Please ask for review again once it's ready.

Comment 53

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Please clear my doubts which I mentioned in github. I will update according to your suggestion. 

Thanks a lot for your taking time and helping me.

Comment 54

[Julien Wajsberg [:julienw]]

Commented on github.

Comment 55

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Hi julien

I will upload a patch with all of your comments soon . Thanks for helping me.

Comment 56

[Julien Wajsberg [:julienw]]

Thanks for your work !

Comment 57

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: Home Screen Fast Swipe

Hi,

I added new patch considering your comments. I tried to reduce duplicated code as much as possible. 

We should not use existing swipe_friction or swipe_threshold to trigger homescreen earlyswipe. 

swipe_friction or swipe_threshold is used for in existing onTouchEnd() function to trigger slow pan. if user changes swipe_friction or swipe_threshold then it will effect existing slow pan. 

If we use same variable to trigger newly implemented earlyswipe then user cannot change threshold of earlyswipe without modify threshold of existing slow pan. 

Resulted behaviour will not good from user's point of view . Because user will like to change earlyswipe threshold without changing threshold of existing slow pan. In other words, earlyswipe threshold should work irrespective of exising slow pan threshold.


I am really sorry for delayed uploading new patch. I was busy in some other task. Please review it and let me know if I can do more changes.

Comment 58

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Julien Wajsberg [:julienw] from comment #56)
> Thanks for your work !

I also used bigger value in swipe_velocity_threshold = 0.04; 

I can make it more bigger if you suggest. 

Thanks for your help

Comment 59

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Comment on attachment 799914 [details]
Home Screen Fast Swipe

Hi Vivian,

Can you please review this ? It seems to me Julein is either busy or in holiday from 'bugzilla suggested reviewers' .

Thanks for your help

Comment 60

[Julien Wajsberg [:julienw]]

Comment on attachment 799914 [details]
Home Screen Fast Swipe

I'm here ;) and Vivien is probably busier than me !

Will review again today

Comment 61

[Julien Wajsberg [:julienw]]

Cristian, I'd like your advice on [1] and the answer in comment 57.

Thanks !

[1] https://github.com/mozilla-b2g/gaia/pull/11084#discussion_r5842860

Comment 62

[Julien Wajsberg [:julienw]]

Tapas, we looked at it with Vivien, and we compared with an Android 4, and we think we should wait for touchend before swiping, otherwise it's very strange for the user, to swipe while the finger is still on the screen.

However, we can probably improve the existing panning, like having a factor for swiping faster if the velocity is high enough ?

Also, in the current homescreen, we can feel a little 'resistance', and I think that with your patch we don't have this resistance anymore... maybe you could do a patch to remove only this ?

Thanks again for your patch, but we just don't feel that swiping before touchend is necessary or even desirable.

Comment 63

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Julien Wajsberg [:julienw] from comment #62)
> Also, in the current homescreen, we can feel a little 'resistance', and I think that with your patch we don't have 
> this resistance anymore... maybe you could do a patch to remove only this ?

This is happening because we are doing pan in 1st touchmove and waiting for touchend. Not sure how to minimize that delay without doing a full page transition based of some velocity condition. 

Thanks for your help. :) .

Comment 64

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Closing this issue as we don't want to see early full page swipe before 'touchend' event.

Comment 65

[Julien Wajsberg [:julienw]]

I'd still would like to thank you because I learnt a lot about how the swipe is working by reviewing your patch.

I think the resistance is because we're waiting for the second touchmove before moving: the first touchmove only set the new touchmove handler.

Comment 66

[Cristian Rodriguez (:crdlc)]

(In reply to Julien Wajsberg [:julienw] from comment #62)
> Tapas, we looked at it with Vivien, and we compared with an Android 4, and
> we think we should wait for touchend before swiping, otherwise it's very
> strange for the user, to swipe while the finger is still on the screen.
> 
> However, we can probably improve the existing panning, like having a factor
> for swiping faster if the velocity is high enough ?
> 
> Also, in the current homescreen, we can feel a little 'resistance', and I
> think that with your patch we don't have this resistance anymore... maybe
> you could do a patch to remove only this ?
> 
> Thanks again for your patch, but we just don't feel that swiping before
> touchend is necessary or even desirable.

I really think so, I agree with you