1120949 - [FFOS7715 v2.1][system]Pull down the utility tray, is not very smooth, not timely

Status: RESOLVED WONTFIX

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

Description

[zhaoyang]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141119030200

Steps to reproduce:

Pull down the  utility tray


Actual results:

is not very smooth, not timely


Expected results:

smooth and timely

Comment 1

[zhaoyang]

Hi Kevin，

   I think it happens because upload ‘touchmove’ event not timely.
   
   Do you aware of the situation？ Or give me some guidance?

   please help me to investigate
   
   Thanks a lot

Comment 2

[Kevin Grandon :kgrandon]

Adding qawanted - can we get branch checks here?

Chris - could you take this needinfo? You are awesome at this kind of stuff, and I think you've done more with the utility tray than I have recently. No worries if you can't, let me know and we can find someone else. Thanks!

Comment 3

[Chris Lord [:cwiiis]]

I won't clear my needinfo right now, but I don't have the time to look into this for at least another week I don't think, possibly two. If we want it looking at before then, may be best to ask someone else (vingtetun and etienne have done a lot of work on this).

Comment 4

[Brogan Zumwalt [Inactive]]

I see a very noticeable lag in the animation when dismissing/pushing the utility tray up. Is this what you are talking about (video example: http://youtu.be/1QTt3dlbqVc)

There is a slight delay when pulling tray down as well.


Issue DOES occur on Flame 2.2 and Flame 3.0

Pulling down and pushing up animation of utility tray experiences visual lag and appears to not to animate smoothly especially on the pushing up dismissal animation of the tray.

Device: Flame 2.2
BuildID: 20150114002502
Gaia: 7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko: 748b20315f75
Version: 37.0a2 (2.2)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device:  Flame 3.0 Master
BuildID: 20150114010205
Gaia: e2a0f7c311119d4a8e160bdfb9e28a0e61a180fc
Gecko: 63006936ab99
Version: 38.0a1 (3.0)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0


Issue does NOT occur in Flame 2.0

Pulling down and pushing up animation of utility tray does not experience visual lag and appears to animate smoothly.

Device: Flame 2.0
BuildID: 20150114000207
Gaia: 31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
Gecko: f2b6017e84eb
Version: 32.0 (2.0)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 5

[yong.ren]

   (In reply to Chris Lord [:cwiiis] from comment #3)
> I won't clear my needinfo right now, but I don't have the time to look into
> this for at least another week I don't think, possibly two. If we want it
> looking at before then, may be best to ask someone else (vingtetun and
> etienne have done a lot of work on this).
Hi vingtetun and etienne: 

   As comment 3, could you please give some guidance about this problem, thanks very much!

Comment 6

[zhaoyang]

Hi vingtetun and etienne,

   Could you help me to answer these questions?

   Is ‘TabParent::InjectTouchEvent‘ related to the issure？
   How is the relationship between ‘TabParent::InjectTouchEvent‘ and 'drag statusbar'?
  
   Thanks a lot

Comment 7

[Etienne Segonzac (:etienne)]

I won't be able to help with the gecko part.
That said it's probably worth checking again now that bug 1074332 landed.

Comment 8

[Chris Lord [:cwiiis]]

So, there is only so smooth interactions like this and edge-swipe are going to be without us throttling the priority of the active application because input is handled on the main thread and I believe that the main thread can get bogged down when there is a CPU-intensive app in the foreground.

So I suppose bug 930939 would help, but also Vivien's work in bug 1061969. I wonder if the idea/work in that bug is more viable now that bug 1081871 has been fixed? Maybe this could hang off of bug 994518 even.

Comment 10

[Chris Lord [:cwiiis]]

For what it's worth, this and edge-swiping are much smoother after applying the patches on bug 930939.

I think this should just block on that work. As I say in comment #8, there's only so much we can do when we're not controlling what apps are running and those apps can bog down input event handling.

Comment 11

[zhaoyang]

Hi chris lord，

   whether bug 930939 will land on 2.1&2.1s？
   Or could you tell me who I can ask？ 

   thanks a lot

Comment 12

[Chris Lord [:cwiiis]]

(In reply to zhaoyang from comment #11)
> Hi chris lord，
> 
>    whether bug 930939 will land on 2.1&2.1s？
>    Or could you tell me who I can ask？ 
> 
>    thanks a lot

This was answered by kats on another bug. (short answer: no)

Comment 13

[yong.ren]

Hi vance:

   this issue is very import to our performance test and user experience, please help to assign some one to investigate it, thanks

Comment 14

[zhaoyang]

2.1s正常匀速下拉：
03-03 00:40:08.447 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:153 in ut_handleEvent: 7715_v2.1s:utility_tray touchstart
03-03 00:40:08.627 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.627 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.627 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.627 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.627 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.877 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.877 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.877 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.887 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.887 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.887 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.887 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.887 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.887 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.897 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.897 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.117 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.127 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.127 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.127 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.127 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.127 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.127 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.157 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.157 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.157 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.157 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.157 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.167 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.167 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.167 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.167 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.167 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove

1.4正常匀速下拉：
03-03 00:54:50.728 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:95 in ut_handleEvent: 7715_v1.4:utility_tray touchstart
03-03 00:54:50.728 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:50.998 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:50.998 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.008 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.008 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.078 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.078 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.118 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.118 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.168 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.168 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.208 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.208 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.228 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.268 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:51.268 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove

Comment 15

[zhaoyang]

1.4下拉过程中只会在start时touch事件间隔较大，而2.1s下拉过程除了start时的间隔大，还有两次明显接收touch事件间隔较大，导致下拉卡顿

Comment 16

[zhaoyang]

(In reply to zhaoyang from comment #15)
> 1.4下拉过程中只会在start时touch事件间隔较大，而2.1s下拉过程除了start时的间隔大，还有两次明显接收touch事件间隔较大，导致下拉卡顿

sorry! update my comment

1.4 Pull down the utility tray,only when ‘touchstart‘ with large time gap, 
2.1s Pull down the utility tray，except ‘touchstart‘ with large time gap,there are two other large time interval between ‘touchmove‘
So maybe this bug was caused by the difference of gecko handling touch events when upgrade 1.4 to 2.1 

1.4 Pull down(one large time interval)：
03-03 00:54:50.728 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:95 in ut_handleEvent: 7715_v1.4:utility_tray touchstart
03-03 00:54:50.728 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove
03-03 00:54:50.998 E/GeckoConsole( 1047): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:113 in ut_handleEvent: 7715_v1.4:utility_tray touchmove  

2.1s Pull down(three large time interval)：
03-03 00:40:08.447 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:153 in ut_handleEvent: 7715_v2.1s:utility_tray touchstart
03-03 00:40:08.627 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
...
03-03 00:40:08.627 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:08.877 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
...
03-03 00:40:08.897 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove
03-03 00:40:09.117 E/GeckoConsole(26730): Content JS LOG at app://system.gaiamobile.org/js/utility_tray.js:177 in ut_handleEvent: 7715_v2.1s:utility_tray touchmove

Comment 17

[siiaceon]

obviously ferformance, need goon making even better

Comment 18

[zhaoyang]

Hi vance & shawn:

   This problem is very serious impact on the user experience, but we didn't find a effective way to improve. Please help to find someone to have a look?

   Thanks a lot

Comment 19

[zhaoyang]

v2.1 add “GeckoTouchDispatcher.cpp”,and there is obvious difference between v1.4 and v2.1

v1.4:GeckoInputDispatcher::notifyMotion() call nsAppShell::NotifyNativeEvent()
v2.1:GeckoInputDispatcher::notifyMotion() call GeckoTouchDispatcher::NotifyTouch()

Comment 20

[zhaoyang]

Hi Mason & Michael,

   Could you help or give some advices about this bug?

   Thanks a lot

Comment 21

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

ni Steven Yang as well to see if someone from the device team can help

Comment 22

[Steven Yang [:styang]]

I'm adding Danny here to check if he can help on this.

Comment 23

[Mason Chang [Inactive] [:mchang]]

In 2.1, we landed but did not enable touch resampling. In 2.2 and master, touch resampling and the vsync compositor are enabled by default which should help smoothness. Is it just not smoother while it's tracking your finger or is it just the initial pulldown of the notification bar? In these cases, it's better to get a profile (https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler), post the profile here and we might get some data on what's being slow.

Comment 24

[zhaoyang]

(In reply to Mason Chang [:mchang] from comment #23)
> In 2.1, we landed but did not enable touch resampling. In 2.2 and master,
> touch resampling and the vsync compositor are enabled by default which
> should help smoothness. Is it just not smoother while it's tracking your
> finger or is it just the initial pulldown of the notification bar? In these
> cases, it's better to get a profile
> (https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
> Profiling_with_the_Built-in_Profiler), post the profile here and we might
> get some data on what's being slow.

Hi Mason,
   As comment16,it is not smooth while both it's tracking your finger and the initial pull down.I will try to get a profile and post the profile here later.Could you help land about resampling and vsync compositor or give a patch?
   Thanks a lot!

Comment 25

[zhaoyang]

(In reply to Mason Chang [:mchang] from comment #23)
> In 2.1, we landed but did not enable touch resampling. In 2.2 and master,
> touch resampling and the vsync compositor are enabled by default which
> should help smoothness. Is it just not smoother while it's tracking your
> finger or is it just the initial pulldown of the notification bar? In these
> cases, it's better to get a profile
> (https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
> Profiling_with_the_Built-in_Profiler), post the profile here and we might
> get some data on what's being slow.

Hi Mason,
   Here is profile，please
   The operation of my steps:pull down utility_tray and pull up utility_tray
   Thanks a lot

Comment 26

[zhaoyang]

Attachment: touch-profile.zip

profile----pull down and pull up utility_tray

Comment 27

[Danny Liang [:dliang]]

(In reply to zhaoyang from comment #26)
> Created attachment 8579773 [details]
> touch-profile.zip
> 
> profile----pull down and pull up utility_tray

By my observation, b2g spent most time on epoll_wait, I don't think it's profiling on pull down utility tray.

Comment 28

[Danny Liang [:dliang]]

Attachment: gecko-profile-v2.1s-0319.tar.gz

Update gecko profile by my test.

Comment 29

[Mason Chang [Inactive] [:mchang]]

Hmm, the profile looks pretty empty. What exactly are you doing to test? Can you make a video of the test? What device are you on as well. Master looks pretty smooth to me.

(In reply to zhaoyang from comment #24)
> (In reply to Mason Chang [:mchang] from comment #23)
> Hi Mason,
>    As comment16,it is not smooth while both it's tracking your finger and
> the initial pull down.I will try to get a profile and post the profile here
> later.Could you help land about resampling and vsync compositor or give a
> patch?
>    Thanks a lot!

Resampling is in 2.1 already. The vsync compositor will not be uplifted to 2.1 since it is too risky, but it is in 2.2.

You can try resampling in 2.1 by enabling these prefs:

gfx.vsync.hw-vsync.enabled
gfx.touch.resample

Set them to true.

Comment 30

[zhaoyang]

(In reply to Mason Chang [:mchang] from comment #29)
> Hmm, the profile looks pretty empty. What exactly are you doing to test? Can
> you make a video of the test? What device are you on as well. Master looks
> pretty smooth to me.
> 
> (In reply to zhaoyang from comment #24)
> > (In reply to Mason Chang [:mchang] from comment #23)
> > Hi Mason,
> >    As comment16,it is not smooth while both it's tracking your finger and
> > the initial pull down.I will try to get a profile and post the profile here
> > later.Could you help land about resampling and vsync compositor or give a
> > patch?
> >    Thanks a lot!
> 
> Resampling is in 2.1 already. The vsync compositor will not be uplifted to
> 2.1 since it is too risky, but it is in 2.2.
> 
> You can try resampling in 2.1 by enabling these prefs:
> 
> gfx.vsync.hw-vsync.enabled
> gfx.touch.resample
> 
> Set them to true.


Hi Mason,

  I add   pref("gfx.vsync.hw-vsync.enabled",true);
          pref("gfx.touch.resample",true);
  in gecko/b2g/app/b2g.js

  If this works，will it call "GeckoTouchDispatcher::ResampleTouchMoves()" ?
  But I add log in this function,and I can't catch that log.
  whether I add in wrong position?

Comment 31

[Mason Chang [Inactive] [:mchang]]

Hm, that should be right. 2.1 really wasn't supported to other things could have changed. You can check in HwcComposer2D.cpp that vsync is occurring. But if it is still janky on master / 2.2, then it won't help you much. What exactly are you testing? Getting a profile would be better so we could actually pinpoint what's happening.

Comment 32

[zhaoyang]

(In reply to Mason Chang [:mchang] from comment #31)
> Hm, that should be right. 2.1 really wasn't supported to other things could
> have changed. You can check in HwcComposer2D.cpp that vsync is occurring.
> But if it is still janky on master / 2.2, then it won't help you much. What
> exactly are you testing? Getting a profile would be better so we could
> actually pinpoint what's happening.


Hi Mason,
   I have tried. Maybe vsync and resample both wasn't supported in 2.1. Whether can change the way of dispatch touch event from 2.1 to 1.4 in local,since 1.4 is more smooth. Or others?
   I add new profile
   Thanks a lot

Comment 33

[zhaoyang]

Attachment: profile.zip

phone is in homescreen,I pull down and pull up utility_tray

Comment 34

[zhaoyang]

(In reply to Danny Liang [:dliang] from comment #27)
> (In reply to zhaoyang from comment #26)
> > Created attachment 8579773 [details]
> > touch-profile.zip
> > 
> > profile----pull down and pull up utility_tray
> 
> By my observation, b2g spent most time on epoll_wait, I don't think it's
> profiling on pull down utility tray.

Hi liang,
   You are right. It's my negligence.
   Could you help analyze this bug?
   Thanks a lot

Comment 35

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Mason, the profile is attached as Comment#33, could you help to check and provide some insights to our partner?

Thanks

Comment 36

[Mason Chang [Inactive] [:mchang]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #35)
> Hi Mason, the profile is attached as Comment#33, could you help to check and
> provide some insights to our partner?
> 
> Thanks

There is nothing in the profile. Can you please provide exactly what you're testing and how?

1) Is it smooth on master / 2.2?
2) Can you please profile the compositor thread? Use the command ./profile.sh start -p b2g -t Compositor && ./profile.sh start -p Homescreen.

Comment 37

[zhaoyang]

(In reply to Mason Chang [:mchang] from comment #36)
> (In reply to Vance Chen [:vchen][[e-mail]] from comment #35)
> > Hi Mason, the profile is attached as Comment#33, could you help to check and
> > provide some insights to our partner?
> > 
> > Thanks
> 
> There is nothing in the profile. Can you please provide exactly what you're
> testing and how?
> 
> 1) Is it smooth on master / 2.2?
> 2) Can you please profile the compositor thread? Use the command
> ./profile.sh start -p b2g -t Compositor && ./profile.sh start -p Homescreen.

I use command ./profile.sh start -p b2g -i 5 && ./profile.sh start -p Homescreen，and catch "profile.zip"
But when I use command ./profile.sh start -p b2g -t Compositor && ./profile.sh start -p Homescreen
I catch the profile spend most time on epoll_wait. 

Or there is a profile on pull down utility tray as comment 27
Also I find it consume a lot of CPU when pulldown of the notification bar

Comment 38

[Danny Liang [:dliang]]

(In reply to zhaoyang from comment #37)
> (In reply to Mason Chang [:mchang] from comment #36)
> > (In reply to Vance Chen [:vchen][[e-mail]] from comment #35)
> > > Hi Mason, the profile is attached as Comment#33, could you help to check and
> > > provide some insights to our partner?
> > > 
> > > Thanks
> > 
> > There is nothing in the profile. Can you please provide exactly what you're
> > testing and how?
> > 
> > 1) Is it smooth on master / 2.2?
> > 2) Can you please profile the compositor thread? Use the command
> > ./profile.sh start -p b2g -t Compositor && ./profile.sh start -p Homescreen.
> 
> I use command ./profile.sh start -p b2g -i 5 && ./profile.sh start -p
> Homescreen，and catch "profile.zip"
> But when I use command ./profile.sh start -p b2g -t Compositor &&
> ./profile.sh start -p Homescreen
> I catch the profile spend most time on epoll_wait. 
> 
it's normal if b2g is doing nothing.

> Or there is a profile on pull down utility tray as comment 27
> Also I find it consume a lot of CPU when pulldown of the notification bar

My profiling result by top on dolphin and flame as following:
1. flame w/ 1 cpu and 319MB on v2.1 didn't have this performance issue, the cpu usage is lower than dolphin under same test environment.
2. On dolphin device, v2.1s gets higher CPU usage than v1.4. This should be why we didn't see this issue on v1.4 but v2.1s did.

Comment 39

[zhaoyang]

(In reply to Danny Liang [:dliang] from comment #38)
> (In reply to zhaoyang from comment #37)
> > (In reply to Mason Chang [:mchang] from comment #36)
> > > (In reply to Vance Chen [:vchen][[e-mail]] from comment #35)
> > > > Hi Mason, the profile is attached as Comment#33, could you help to check and
> > > > provide some insights to our partner?
> > > > 
> > > > Thanks
> > > 
> > > There is nothing in the profile. Can you please provide exactly what you're
> > > testing and how?
> > > 
> > > 1) Is it smooth on master / 2.2?
> > > 2) Can you please profile the compositor thread? Use the command
> > > ./profile.sh start -p b2g -t Compositor && ./profile.sh start -p Homescreen.
> > 
> > I use command ./profile.sh start -p b2g -i 5 && ./profile.sh start -p
> > Homescreen，and catch "profile.zip"
> > But when I use command ./profile.sh start -p b2g -t Compositor &&
> > ./profile.sh start -p Homescreen
> > I catch the profile spend most time on epoll_wait. 
> > 
> it's normal if b2g is doing nothing.
> 
> > Or there is a profile on pull down utility tray as comment 27
> > Also I find it consume a lot of CPU when pulldown of the notification bar
> 
> My profiling result by top on dolphin and flame as following:
> 1. flame w/ 1 cpu and 319MB on v2.1 didn't have this performance issue, the
> cpu usage is lower than dolphin under same test environment.
> 2. On dolphin device, v2.1s gets higher CPU usage than v1.4. This should be
> why we didn't see this issue on v1.4 but v2.1s did.

Indeed，flame consume CPU far lower than dolphin when pulldown of the notification bar.
But I test v1.4 and v2.1s on dolphin, v1.4 is a little lower than v2.1s.
In v2.1s,statusbar is a part of APP chromebar,and it's not in v1.4.
Whether it more rely on cpu,when dispatcher touch events on v2.1s?

Comment 40

[Danny Liang [:dliang]]

(In reply to zhaoyang from comment #39)
> (In reply to Danny Liang [:dliang] from comment #38)
> > (In reply to zhaoyang from comment #37)
> > > (In reply to Mason Chang [:mchang] from comment #36)
> > > > (In reply to Vance Chen [:vchen][[e-mail]] from comment #35)
> > > > > Hi Mason, the profile is attached as Comment#33, could you help to check and
> > > > > provide some insights to our partner?
> > > > > 
> > > > > Thanks
> > > > 
> > > > There is nothing in the profile. Can you please provide exactly what you're
> > > > testing and how?
> > > > 
> > > > 1) Is it smooth on master / 2.2?
> > > > 2) Can you please profile the compositor thread? Use the command
> > > > ./profile.sh start -p b2g -t Compositor && ./profile.sh start -p Homescreen.
> > > 
> > > I use command ./profile.sh start -p b2g -i 5 && ./profile.sh start -p
> > > Homescreen，and catch "profile.zip"
> > > But when I use command ./profile.sh start -p b2g -t Compositor &&
> > > ./profile.sh start -p Homescreen
> > > I catch the profile spend most time on epoll_wait. 
> > > 
> > it's normal if b2g is doing nothing.
> > 
> > > Or there is a profile on pull down utility tray as comment 27
> > > Also I find it consume a lot of CPU when pulldown of the notification bar
> > 
> > My profiling result by top on dolphin and flame as following:
> > 1. flame w/ 1 cpu and 319MB on v2.1 didn't have this performance issue, the
> > cpu usage is lower than dolphin under same test environment.
> > 2. On dolphin device, v2.1s gets higher CPU usage than v1.4. This should be
> > why we didn't see this issue on v1.4 but v2.1s did.
> 
> Indeed，flame consume CPU far lower than dolphin when pulldown of the
> notification bar.
> But I test v1.4 and v2.1s on dolphin, v1.4 is a little lower than v2.1s.
> In v2.1s,statusbar is a part of APP chromebar,and it's not in v1.4.
> Whether it more rely on cpu,when dispatcher touch events on v2.1s?

By top, I found b2g main thread consume more CPU but Compositor thread is hard to get resource.
By systrace, we found b2g spent more time in "DispatchEvent" on v2.1s

Comment 41

[Danny Liang [:dliang]]

Attachment: pull-utility-tray.tar.gz

systrace profiling file when pulling utility tray on both v2.1s and v1.4

Comment 42

[zhaoyang]

(In reply to Danny Liang [:dliang] from comment #41)
> Created attachment 8585921 [details]
> pull-utility-tray.tar.gz
> 
> systrace profiling file when pulling utility tray on both v2.1s and v1.4

wether there is someting we can do to reduce consume CPU?

Comment 43

[zhaoyang]

Hi Danny Liang &  Mason Chang,

   If change reporting frequency from 70HZ to 50HZ（dolphin）, it will be smooth. Also can reduce the CPU usage, whether this will bring risk?

   Thanks a lot！

Comment 44

[Mason Chang [Inactive] [:mchang]]

(In reply to zhaoyang from comment #43)
> Hi Danny Liang &  Mason Chang,
> 
>    If change reporting frequency from 70HZ to 50HZ（dolphin）, it will be
> smooth. Also can reduce the CPU usage, whether this will bring risk?
> 
>    Thanks a lot！

Can you please elaborate? What is the reporting frequency? I don't understand what you are changing here.

Comment 45

[zhaoyang]

(In reply to Mason Chang [:mchang] from comment #44)
> (In reply to zhaoyang from comment #43)
> > Hi Danny Liang &  Mason Chang,
> > 
> >    If change reporting frequency from 70HZ to 50HZ（dolphin）, it will be
> > smooth. Also can reduce the CPU usage, whether this will bring risk?
> > 
> >    Thanks a lot！
> 
> Can you please elaborate? What is the reporting frequency? I don't
> understand what you are changing here.

change touch event reporting frequency from 70HZ to 50HZ（dolphin）,just as follow:
static int ft5x0x_ts_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
        ...
	/* set report rate, about 70HZ */
	ft5x0x_write_reg(FT5X0X_REG_PERIODACTIVE, 7);
        ...
}
I have test this change has no effect on the other APP,it looks good.I want to ask whether this will bring risk?

Comment 46

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi ZhaoYang -

I don't Mozilla can comment much on this since it is more driver/Touch Panel characteristics relevant. But still ni Viral to see if he has any suggestion here

Thanks

Comment 47

[Danny Liang [:dliang]]

(In reply to zhaoyang from comment #45)
> (In reply to Mason Chang [:mchang] from comment #44)
> > (In reply to zhaoyang from comment #43)
> > > Hi Danny Liang &  Mason Chang,
> > > 
> > >    If change reporting frequency from 70HZ to 50HZ（dolphin）, it will be
> > > smooth. Also can reduce the CPU usage, whether this will bring risk?
> > > 
> > >    Thanks a lot！
> > 
> > Can you please elaborate? What is the reporting frequency? I don't
> > understand what you are changing here.
> 
> change touch event reporting frequency from 70HZ to 50HZ（dolphin）,just as
> follow:
> static int ft5x0x_ts_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> {
>         ...
> 	/* set report rate, about 70HZ */
> 	ft5x0x_write_reg(FT5X0X_REG_PERIODACTIVE, 7);
>         ...
> }
> I have test this change has no effect on the other APP,it looks good.I want
> to ask whether this will bring risk?

My comment is same as Vance's, but I am curious whether we use same touch driver and sampling rate in dolphin with 256MB/512MB. Is there any extra difference except memory size and storage?

Comment 48

[viral [:viralwang]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #46)
> Hi ZhaoYang -
> 
> I don't Mozilla can comment much on this since it is more driver/Touch Panel
> characteristics relevant. But still ni Viral to see if he has any suggestion
> here
> 
> Thanks

lower report rate in touch driver is an useful way to decrease cpu usage but it will make the response time a little bit longer. Like Danny mentioned in comment 47, we may check the difference to we used to be in dolphin.