Closed Bug 1141053 Opened 9 years ago Closed 9 years ago

[Contacts][dolphin][FFOS7715 v2.1s][performance] poor performance in contacts list scrolling

Categories

(Firefox OS Graveyard :: Performance, defect)

Product:
Firefox OS Graveyard
Component:
Performance
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(blocking-b2g:2.1S+, b2g-v2.1S fixed, b2g-v2.2 unaffected, b2g-master unaffected)

Status:
RESOLVED FIXED
Milestone:
2.2 S10 (17apr)
Project Flags:
blocking-b2g 2.1S+
Tracking Flags:
Tracking Status
b2g-v2.1S --- fixed
b2g-v2.2 --- unaffected
b2g-master --- unaffected

People

(Reporter: shiwei.zhang, Assigned: jerry)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(7 files, 2 obsolete files)

VID_0003.3gp
5.25 MB, video/3gpp
Details
contacts_list_scrolling_compositor.zip
264.96 KB, application/zip
Details
scrolling profile data on dolphin
203 bytes, text/plain
Details
Part2: raise compositor thread priority. v1
1.26 KB, patch
roc
: review+
Details | Diff | Splinter Review
Part1: apply occlusion culling
17.52 KB, patch
mattwoodrow
: review+
Details | Diff | Splinter Review
after-culling.zip
363.89 KB, application/zip
Details
before-culling.zip
351.26 KB, application/zip
Details 
*** Build Information
Gaia-Rev        37c364a4b055ca8ae7bb08dcd9ee6373771c78fd
Gecko-Rev       dc1154beadf9845a8783c1ccb1ed75c101ea8b1e
Device-Name     dolphin


*** Expected Results
contacts list scrolling fluently

*** Actual Results
some flicker in contacts list scrolling.
not smoothly , just on low configuration such as poor cpu.
pls shiwei tick related information out with ben including vedio better. so that easy to make mozilla know what's the point.
The issue was recorded in this the vedio.

ftp://ftp.spreadtrum.com/7715/1141053/CIMG5256-contacts-scroll.MOV.zip

username:mouzhi
password:mouZHI$$61
CPU and MEM info

(1) User 74%, System 12%, IOW 0%, IRQ 0%
User 69 + Nice 170 + Sys 39 + Idle 41 + IOW 0 + IRQ 0 + SIRQ 0 = 319

  PID   TID PR CPU% S     VSS     RSS PCY UID      Thread          Proc
 2903  2903  0  53% R 113356K  54344K  fg u0_a2903 Communications  /system/b2g/b2g
  130   559  0  18% S 216768K  94444K  fg root     Compositor      /system/b2g/b2g
  130   130  0   5% S 216768K  94444K  fg root     b2g             /system/b2g/b2g
 3276  3276  0   2% R   1372K    592K  fg root     top             top
  130   391  0   1% S 216768K  94444K  fg root     Timer           /system/b2g/b2g


(2)|     megabytes     |
           NAME  PID PPID CPU(s) NICE  USS  PSS  RSS SWAP VSIZE OOM_ADJ USER    
            b2g  130    1 5232.7    0 69.1 74.7 91.9  0.0 212.1       0 root    
         (Nuwa)  313  130    2.3    0  2.2  4.0 12.9  0.0  52.0     -15 root    
     Homescreen  587  313   24.2   18  9.7 12.5 26.1  0.0  67.7       9 u0_a587 
Built-in Keyboa  661  130    3.7   18 12.8 17.2 30.1  0.0  69.5      12 u0_a661 
        Browser  792  313    2.0   18  7.8 10.2 22.9  0.0  62.7      13 u0_a792 
 Communications 2903  313  275.0    1 36.0 39.2 53.1  0.0 113.4       2 u0_a2903
(Preallocated a 3200  313    0.5   18  5.6  7.6 18.2  0.0  59.9       1 u0_a3200

System memory info:

            Total 469.3 MB
        SwapTotal 300.0 MB
     Used - cache 219.4 MB
  B2G procs (PSS) 165.4 MB
    Non-B2G procs  54.0 MB
     Free + cache 249.9 MB
             Free  13.0 MB
            Cache 236.9 MB
         SwapFree 298.3 MB

Low-memory killer parameters:

  notify_trigger 14336 KB

  oom_adj min_free
        0  4096 KB
        1  5120 KB
        2  6144 KB
        6  7168 KB
        8  8192 KB
       10 20480 KB
Upload video here:

https://www.youtube.com/watch?v=qv6w3E-pMy8&feature=youtu.be

SPRD will help to provide fps data later

Thanks
Flags: needinfo?(siiaceon.cao)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #4)
Dear Vance,
  We meet a similar issue in homescreen (moz bug1141047). I think maybe both these issue are the same root.
  Could you please help to make a corresponding test together on Dolphin and Flame? I think Mike Lien‘s data is more professional.


Thanks a lot.
In my experiment fps are not more than 50.
Dear Vance, if you are fully occupied, could you tell us your method of FPS test? What I used is developer HUD in settings app.

Thank you.
(In reply to Shiwei Zhang from comment #7)
> Dear Vance, if you are fully occupied, could you tell us your method of FPS
> test? What I used is developer HUD in settings app.
> 
> Thank you.

Hi shiwei: 

  please refer to Bug 1141047 comment 13 and Bug 1141047 comment 15 to get their test methods.
Are you sure apzc is enabled ?
Component: Layout → Panning and Zooming
Whiteboard: [gfx-noted]
Can you please provide the exact versions of code (including gecko + gaia SHAs) running on the flame and dolphin devices shown in comment 4? They don't look like they're the same code because the alphabet icons on the right side of the contacts app are different colors.
Flags: needinfo?(shiwei.zhang)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #10)

Hi Kartikaya，
 Here are the versions code.

(1) Dolphin:
Gaia-Rev        a66813e488374b8ba9d8aa187b00f84ad5bd1bb9
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/ee8a2d1b86a5
Build-ID        20150311161202
Version         34.0
Device-Name     scx15_sp7715ea
FW-Release      4.4.2
FW-Incremental  44
FW-Date         Tue Dec 30 13:56:10 CST 2014

(2) Flame
Gaia-Rev        db751d9c200dce41cd03a61665746d245739a175
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/28ffee0d5b0c
Build-ID        20150312001452
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150312.034011
FW-Date         Thu Mar 12 03:40:22 EDT 2015
Bootloader      L1TC100118D0
Flags: needinfo?(shiwei.zhang)
I compared the gaia and gecko code in the above two builds and I couldn't see any change that would explain this behaviour. My only guess is that the hardware is different and so it's slower on one device versus the other. How many cores does Dolphin have? And how much memory?
Actually, the gaia diff doesn't even explain why the alphabet icons are different colors as I noted in comment 10, so I don't know what's going on here.
ni? for the questions in comment 12.
Flags: needinfo?(shiwei.zhang)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #14)
> ni? for the questions in comment 12.

Hi Kartikaya,
  Dolphin has only one core, the same as Flame(we changed it to one core), and both of them have the same memory 512M. 
  To improved performance, we cut down the size of list by changing alphabet icons from images to characters and painting the background with gray. I think these changes would not reduce performance of list scrolling.
Flags: needinfo?(shiwei.zhang)
(In reply to Shiwei Zhang from comment #15)
>   Dolphin has only one core, the same as Flame(we changed it to one core),
> and both of them have the same memory 512M. 

Thanks. In that case I have no idea why the performance is so different on Dolphin. I don't have a Dolphin device so unfortunately I cannot investigate myself. I'm going to redirect this to the FxOS perf component in the hopes that somebody else who can reproduce this can look into it.

>   To improved performance, we cut down the size of list by changing alphabet
> icons from images to characters and painting the background with gray. I
> think these changes would not reduce performance of list scrolling.

How did you make these changes? Are they committed to the 2.1s gaia code branch? I didn't see anything like that when I did a diff of the two gaia revisions you posted in comment 11 - but maybe I just missed it.
Component: Panning and Zooming → Performance
Product: Core → Firefox OS
Version: 37 Branch → unspecified
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #16)

> How did you make these changes? Are they committed to the 2.1s gaia code
> branch? I didn't see anything like that when I did a diff of the two gaia
> revisions you posted in comment 11 - but maybe I just missed it.

Thanks, Kartikaya, the changes are only committed to sprd's gaia patch branch, therefore，you didn't see them in gaia vision.
Dear Vance & Kartikaya,

 We have recorded a new vedio, and in this vedio FPS is displayed during list scrolling.

ftp://ftp.spreadtrum.com/7715/1141053/fps_of_ct_list_scrolling.zip

username:mouzhi
password:mouZHI$$61

Maybe FPS data is limited in a small range.
(In reply to Shiwei Zhang from comment #17)
> 
> Thanks, Kartikaya, the changes are only committed to sprd's gaia patch
> branch, therefore，you didn't see them in gaia vision.

So the build running on the device in the video was not built from the code identified in comment 11? What other changes were made to the sprd branches?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #19)
> (In reply to Shiwei Zhang from comment #17)
> > 
> > Thanks, Kartikaya, the changes are only committed to sprd's gaia patch
> > branch, therefore，you didn't see them in gaia vision.
> 
> So the build running on the device in the video was not built from the code
> identified in comment 11? What other changes were made to the sprd branches?

As I know, SPRD has check-in a few their own performance enhancement or carrier requirements patches into their local repository. 

Hi Shiwei, could you do a rough scrolling performance test on 7715 with vanilla Firefox OS 2.1? We want to make sure if the vanilla 2.1 is slow with 7715

Thanks!
Flags: needinfo?(siiaceon.cao) → needinfo?(shiwei.zhang)
Attached video VID_0003.3gp — 
Dear Vance,
 It is slow on 7715 with vanilla Firefox OS 2.1. please see this video.
Flags: needinfo?(shiwei.zhang)
We did not check-in any patches on this version, and you can also see the FPS is displayed during list scrolling.
Hi Kats, per Comment#21 and Comment#22,  the vanilla 2.1 is also running slower with Dolphin 7715, is there any more information SPRD can provide to help to pinpoint where is the performance bottleneck?

Thanks
Flags: needinfo?(bugmail.mozilla)
Getting a profile while scrolling is probably the most useful thing to do. Please include the contacts process main thread as well as the main process' main thread and compositor threads. The video in comment 21 indicates at least that we're not falling back to sync scrolling, assuming APZ is enabled. (Otherwise we would see a red square in the top-right corner from bug 1053992).
Flags: needinfo?(bugmail.mozilla)
Hi Shiwei, per Comment#24, could you help to capture the profile while scrolling the contact list?

Thanks
Flags: needinfo?(shiwei.zhang)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #24)

Dear kartikaya,
 I haven't got profile before, but I found the guide on this page,

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler#Profiling_Boot_to_Gecko_%28with_a_real_device%29

I created .userconfig in the root of the B2G and writed export MOZ_PROFILING=1 in the first line of this file, then build b2g and flash it into the phone, after this I run

./profile.sh start -p b2g -t Compositor && ./profile.sh start -p Communications

but every time when I run

./profile.sh capture

the results show that

Signaling Profiled Processes: 122 834
Stabilizing 122 b2g ...
Pulling /data/local/tmp/profile_0_122.txt into profile_122_b2g.txt
Unable to locate ./.var.profile
You need to build b2g in order to get symbolic information

So I couldn't get the sym file and head on over to Cleopatra. Is there something wrong with .userconfig, could you give me a hand with an example file and location of this file? 

Thank you very much.
Flags: needinfo?(shiwei.zhang)
Is your build process for Dolphin the same as the one for Flame (i.e. run ./build.sh)? The .var.profile file gets generated from the code at [1]. If it's not getting generated by your build automatically then you can probably just make it manually. For reference mine looks like this, you can just copy it and update the paths as needed to make it reflect your environment.

export GECKO_OBJDIR=/home/kats/zspace/B2G-flame-kk/objdir-gecko
export GECKO_TOOLS_PREFIX=/home/kats/zspace/B2G-flame-kk/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/arm-linux-androideabi-
export PRODUCT_OUT=/home/kats/zspace/B2G-flame-kk/out/target/product/flame

[1] https://github.com/mozilla-b2g/gonk-misc/blob/66428176924305ed638a08423c088d26348fe1ef/Android.mk#L283-L285
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #27)
Dear Kartikaya,
 Following your advice, I have tried several times, when I run ./profile.sh capture something changed, but it went wrong like this,

Signaling Profiled Processes: 122 673
Stabilizing 122 b2g ...
Pulling /data/local/tmp/profile_0_122.txt into profile_122_b2g.txt
Adding symbols to profile_122_b2g.txt and creating profile_122_b2g.sym ...
Stabilizing 673 Communications ...
Pulling /data/local/tmp/profile_2_673.txt into profile_673_Communications.txt
Adding symbols to profile_673_Communications.txt and creating profile_673_Communications.sym ...
Merging profile:  profile_122_b2g.sym profile_673_Communications.sym
./gecko/tools/profiler/merge-profiles.py profile_122_b2g.sym profile_673_Communications.sym
Traceback (most recent call last):
  File "./gecko/tools/profiler/merge-profiles.py", line 91, in <module>
    MergeProfiles(sys.argv[1:])
  File "./gecko/tools/profiler/merge-profiles.py", line 32, in MergeProfiles
    fp = open(fname, "r")
IOError: [Errno 2] No such file or directory: 'profile_122_b2g.sym'

Results: profile_captured.sym
Removing old profile files (from device) ... done

It looks like sym files have not been created, but I don't know what should I do, could you give me some advice?

I'm very grateful to you for your kindly help.
Hi Shiwei, as i know, ZhaoYang (David.Zhao@spreadtrum.com) at your side also knows how to profile firefox OS, maybe you can discuss with him first since you guys are in same company and same timezone?

Thanks
Flags: needinfo?(shiwei.zhang)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #29)

Thank you, Vance, that is greate, I'll ask our guys right now.
Flags: needinfo?(shiwei.zhang)
Attached file contacts_list_scrolling_profile.zip (obsolete) — 
Dear Kartikaya,
  I captured sym files successfully, please see the attachment, if the files are not helpful, please inform me, I'll recapture them in first.
From the profile it looks like the contacts app visibility_monitor.js is the source of at least a few of the slower paints (this is bug 967844). However the main process main thread is pretty empty so we should still be able to pan asynchronously reasonably well. The profile doesn't contain the compositor thread information which would provide more information why that's not happening.

Can you try again making sure to include the Compositor thread in the b2g process along with the two main threads you got here? Thanks.
It's still not confirmed we indeed use APZC here.

Kats, how can we be sure this is used? Simply reading a pref?
I think in 2.1 the developer settings still had an option to control APZ, so you could check that. You could also do the brute-force method - attach gdb, set a breakpoint deep in APZ code to see if it's getting hit.

I have another question though:

(In reply to Shiwei Zhang from comment #15)
>   Dolphin has only one core, the same as Flame(we changed it to one core),
> and both of them have the same memory 512M. 

How did you change the Flame to run on one core? I can't find instructions for that anywhere.
Hi Kartikaya,
  I have captured the sym files including Compositor info, please see this attachment.

> How did you change the Flame to run on one core? I can't find instructions for that anywhere.

We have the images for one core but we can't build it by ourselves, maybe you can ask Vance if you want know more about this.
Attachment #8583684 - Attachment is obsolete: true
Thanks. From this profile it looks like the compositor is chugging along just fine, so I don't know what could be going wrong. Right now the two best guesses are that APZ is disabled or that on a single-core device such as Dolphin this is just going to be expected. Is there some way to confirm that the Flame image you have only uses one core and still behaves better?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #36)
> Thanks. From this profile it looks like the compositor is chugging along
> just fine, so I don't know what could be going wrong. Right now the two best
> guesses are that APZ is disabled or that on a single-core device such as
> Dolphin this is just going to be expected. Is there some way to confirm that
> the Flame image you have only uses one core and still behaves better?

Hi Shiwei -

As I know it should be obsoleted, but could you still help to check if there is a Async Pan/Zoom setting in the developer menu of Setting application?

Also when you do the contact list scrolling on single-core Flame, could you use the following command to make sure that indeed it is running with single core:

adb shell cat /sys/devices/system/cpu/online

value 0 means the device is running with single core

Thanks
Flags: needinfo?(shiwei.zhang)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #37)
Dear Vance, 
  I have checked these features on Dolphine and Flame, they are the same
(1) Async Pan/Zoom is selected.
(2) After command adb shell cat /sys/devices/system/cpu/online, I can see 0 is returned.
Flags: needinfo?(shiwei.zhang)
Hi Kartikaya -

Partner already confirmed that the Async Pan/Zoom is enable in Dolphin 2.1 and Flame is only used single core. So is there anything we can further look into, or is it probably due to the CPU limitation that Flame simply has better performance than Dolphin?

Thanks
Flags: needinfo?(bugmail.mozilla)
this is a partner blocker.
blocking-b2g: --- → 2.1S+
Unfortunately I don't have anything else to suggest at this point without being able to play around with a dolphin device myself.
Flags: needinfo?(bugmail.mozilla)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #41)
Hi Kartikaya,
  Could you help to give a brief overview about how the b2g main thread and Compositor thread work during a scrolling movement？ For instance, the route of event passing. We can measure the time cost by steps.

Thanks a lot.
(In reply to Shiwei Zhang from comment #42)
>   Could you help to give a brief overview about how the b2g main thread and
> Compositor thread work during a scrolling movement？ For instance, the route
> of event passing. We can measure the time cost by steps.

You may find this APZ overview documentation [1] to be helpful, particularly the "Overall flow of input events" and "Threading considerations" sections.

An additional thing to know for B2G is that the input thread is the same as the compositor thread.

(I'm afraid I don't know where an up-to-date rendered version of this documentation can be found.)

[1] http://hg.mozilla.org/mozilla-central/file/18a8ea7c2c62/gfx/doc/AsyncPanZoom.md
(In reply to Botond Ballo [:botond] from comment #43)
> You may find this APZ overview documentation [1] to be helpful, particularly
> the "Overall flow of input events" and "Threading considerations" sections.
> 
> An additional thing to know for B2G is that the input thread is the same as
> the compositor thread.
> 
> (I'm afraid I don't know where an up-to-date rendered version of this
> documentation can be found.)
> 
> [1]
> http://hg.mozilla.org/mozilla-central/file/18a8ea7c2c62/gfx/doc/AsyncPanZoom.
> md

Thank you, Botond.
(In reply to Botond Ballo [:botond] from comment #43)
> (I'm afraid I don't know where an up-to-date rendered version of this
> documentation can be found.)

Looks like GitHub renders it automatically:

https://github.com/mozilla/gecko-dev/blob/master/gfx/doc/AsyncPanZoom.md
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #41)
> Unfortunately I don't have anything else to suggest at this point without
> being able to play around with a dolphin device myself.

Hi Kartikaya - 

I can send you a Dolphin, where should I send the device?

Thanks
Flags: needinfo?(bugmail.mozilla)
If there's one in the Toronto office already, or if you can send one there I can get it from there. However I'm not sure where this will stack up in my priority list of things to do - NI'ing milan for that.
Flags: needinfo?(bugmail.mozilla) → needinfo?(milan)
We do have one in the office, at least the early prototype with the "external" second SIM slot.  Your better bet is to just work within the device team in Taipei.  NI Peter in case he can also help.
Flags: needinfo?(milan) → needinfo?(pchang)
Jerry, please help to check the scrolling behavior in dolphin with the contact app.
Flags: needinfo?(pchang)
Flags: needinfo?(hshih)
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #47)
Hi Kartikaya,
 I made some experiments in changing gecko version, and found that

if I change the gecko with this version

commit 4e3270689602107f062a9eb2fef5e2f2ab2e47bf
Author: Kartikaya Gupta <kgupta@mozilla.com>
Date:   Thu Aug 21 08:36:07 2014 -0400

    Bug 1055932 - Don't build an APZCTreeManager if APZ is disabled. r=botond

As a result, the average value of FPS was more than 50 when contacts list was scrolling.

It means that, we can refer to former gecko version and make some changes in gecko to improve scrolling performance, though this is a very early version.

Do you agree?
Hah, if that patch made a difference then APZ is definitely disabled on your build.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #51)
Yes, of course. 

Maybe APZ consume some cpu time, could you remove this feature by a patch? 

I can test it locally.
Feel free to take bug 1055932 in 2.1s if that helps. It's already in 2.1 so I assumed it was already in 2.1s also. That patch will prevent APZ from consuming CPU time when disabled.
Maybe I'm wrong, but I think that was Shiwei is saying is that when taking gecko at that hash it's working well for them. That means something regressed _since_ that version.

Shiwei, can you confirm this? Also can you tell if the immediate next gecko version is breaking? The best would be to know the first gecko version that breaks the performance on your phone.
Flags: needinfo?(shiwei.zhang)
(In reply to Julien Wajsberg [:julienw] (PTO April 6th) from comment #54)
> Maybe I'm wrong, but I think that was Shiwei is saying is that when taking
> gecko at that hash it's working well for them. That means something
> regressed _since_ that version.
> Shiwei, can you confirm this? 

Yes, but this version
commit 4e3270689602107f062a9eb2fef5e2f2ab2e47bf
Author: Kartikaya Gupta <kgupta@mozilla.com>
Date:   Thu Aug 21 08:36:07 2014 -0400

    Bug 1055932 - Don't build an APZCTreeManager if APZ is disabled. r=botond

is very early.


> Also can you tell if the immediate next gecko version is breaking? 
No, the performance keep smooth the next gecko version, but it drops off slowly and steadily as version increase.  

> The best would be to know the first gecko version that
> breaks the performance on your phone.

I have test dozens of gecko versions based on the same devices with same gaia, gonk, like stated the above, the performance of list scrolling drops off slowly, I am sorry to say that I can't point out which is the first version that performance breaks.

But I feel sure we can do something with gecko to improve performance.
Flags: needinfo?(shiwei.zhang)
I think the next step is Kats to profile a real Dolphin device...
I have a dolphin device, and will do the profiling soon. There are some env setup problems. Checking...
Flags: needinfo?(hshih)
Assignee: nobody → hshih
Status: NEW → ASSIGNED
I can see the blur text(checkboarding?) when I scroll very fast, so I think APZ is on.
When I scroll back and forth in a small range, the fps between dolphin and flame is 38 versus 60.
I will have a compositor profiling later.

This is my gecko test commit:
commit 99eae382f73cd8eecbfebb0b1b7edc1946549854
Author: B2G Bumper Bot <release+b2gbumper@mozilla.com>
Date:   Tue Apr 7 12:17:31 2015 -0700
Hi Jerry,
  Maybe we can take these two points into consideration 
  1. Touch event process are spending more cpu in v2.1 than v1.4.  (may be related with APZ mechanisim). 

  2. compositor thread Priority is lower than the main thread
   when the cpu resources are occupied most by b2g main thread, and the compositor only have little time to deal.

   Could we upgrade the compositor thread priority to imporve it?
This is the profiling result on dolphin with 200 contacts.

We can see the composing tasks are usually scheduled continually. I think that apz works well in this scrolling case.

We spend a lot of time in CompositorOGL::EndFrame(). It almost dominates all composition time. Dolphin doesn't use hwc, so I will check swapBuffer and FB device related code later.

Kats, could you please check this data? I think the bottleneck is at the compositor part.
Flags: needinfo?(bugmail.mozilla)
(In reply to Shiwei Zhang from comment #59)
> Hi Jerry,
>   Maybe we can take these two points into consideration 
>   1. Touch event process are spending more cpu in v2.1 than v1.4.  (may be
> related with APZ mechanisim). 
> 

Do you have profiling data to show that we have higher loading for touch processing?

>   2. compositor thread Priority is lower than the main thread
>    when the cpu resources are occupied most by b2g main thread, and the
> compositor only have little time to deal.
> 
>    Could we upgrade the compositor thread priority to imporve it?

In b2g/app/b2g.js:
pref("hal.gonk.COMPOSITOR.nice", 0); <=== You can set the thread nice value here. Maybe -4 as android surfaceflinger nice value.
(In reply to Jerry Shih[:jerry] (UTC+8) from comment #60)
> We spend a lot of time in CompositorOGL::EndFrame(). It almost dominates all
> composition time. Dolphin doesn't use hwc, so I will check swapBuffer and FB
> device related code later.
> 
> Kats, could you please check this data? I think the bottleneck is at the
> compositor part.

Yeah it does look that way. In the profile it looks like most of the composites are in the 20-25ms range, which means it's blowing past the 16ms budget and will cause us to drop down to a lower fps (~30). I think the time spent in CompositorOGL::EndFrame() is likely just waiting for vsync in the SwapBuffers() call. There might be some other sorts of contentions here (this reminds me very much of bug 1005908) so maybe Sotaro would be a better person to answer questions about this.
Flags: needinfo?(bugmail.mozilla)
There are two calls spent the most time.

a)
GonkDisplayJB::SwapBuffers(EGLDisplay dpy, EGLSurface sur)
{
    ....
    if (mFBDevice && mFBDevice->compositionComplete) {
        mFBDevice->compositionComplete(mFBDevice);   <======
    }
    ....
}


b)
bool
GonkDisplayJB::Post(buffer_handle_t buf, int fence)
{
    ....
    if (!mHwc) {
        if (fence >= 0)
            close(fence);
        return !mFBDevice->post(mFBDevice, buf);  <=========
    }
    ....
}

For a), the fd impl for compositionComplete() is at [1]. It call glFinish(). It costs about 10ms when scrolling.

int compositionComplete(struct framebuffer_device_t *dev)
{
  glFinish();
}

For b), the post impl is also at [1]. B2g spends about 15 ms for this post function. Most of time spent at |ioctl(m->framebuffer->fd, FBIOPUT_VSCREENINFO, &m->info)| ioctl call.

Shiwei, could you please check these function?

[1]
B2G/vendor/sprd/open-source/libs/gralloc/framebuffer_device.cpp
Flags: needinfo?(shiwei.zhang)
Also ni Yong Ren here
Flags: needinfo?(yong.ren)
thanks jerry and vance, I will investigate these two calls quickly. 

1. vendor/sprd/open-source/libs/gralloc/framebuffer_device.cpp:419:               
if (ioctl(m->framebuffer->fd, FBIOPUT_VSCREENINFO, &m->info) == -1) 

2.vendor/sprd/open-source/libs/gralloc/framebuffer_device.cpp: 732

 int compositionComplete(struct framebuffer_device_t *dev)
{
	/* By doing a finish here we force the GL driver to start rendering
	   all the drawcalls up to this point, and to wait for the rendering to be complete.*/
	glFinish();

Hi Jerry: 

  do you mean the above two calls cost a lot of time, thanks.
Flags: needinfo?(yong.ren) → needinfo?(hshih)
Yong,
Yes, you can have some log at framebuffer_device.cpp:fb_post() and framebuffer_device.cpp:compositionComplete() function.
Flags: needinfo?(hshih)
(In reply to yong.ren from comment #65)
Thank you for your timely help. I am occupied in checking a form issue of contacts app，but I'll investigate it as soon as I can.
Flags: needinfo?(shiwei.zhang)
This is the patch from bug-1071156.

From comment 59 and profiling result, compositor is usually in runnable status. We still can't get 60 fps even though we enable culling in Part1. I'm trying to raise compositor thread priority to -4 as v2.2 does. With Part1 and Part2 patch, I can get 16.x ms per frame if we are still in apz display port.
This is the patch from bug-1085223 and bug-1113435.

In layerscope view, we can see the overdraw problem in v2.1s. Dolphin doesn't have a very powerful gpu. If there are too many pixels per frame, we will spend a lot of time in GonkDisplayJB::SwapBuffers() and GonkDisplayJB::Post().
Attached file before-culling.zip (obsolete) — 
The layerscope data before culling.
Attached file after-culling.zip — 
The data after culling.
Please use layerscope tool from [1]. Load attachment 8592164 [details] and attachment 8592165 [details] using [2] and then we can see the difference of painting area.

[1]
https://wiki.mozilla.org/Platform/GFX/LayerScope
[2]
http://mozilla.github.io/layerscope/
Hi Shiwei,
Could you please try the p1 and p2 patch and test the scrolling performance again?
Flags: needinfo?(shiwei.zhang)
(In reply to Jerry Shih[:jerry] (UTC+8) from comment #73)
> Hi Shiwei,
> Could you please try the p1 and p2 patch and test the scrolling performance
> again?

Hi Jerry,
 Thank you for your help, I am trying to test these patchs on 2.1s, and I'll update the test result here promptly.
Dear Jerry,
 The contacts list is scrolling perfectly now, and fps are more than 50 most of the time, your patchs are greate.

Thank you so much.
Flags: needinfo?(shiwei.zhang)
Attached file before-culling.zip — 
sorry, the attachment 8592164 [details] is the result after culling.
upload the new one.
Attachment #8592164 - Attachment is obsolete: true
Comment on attachment 8592160 [details] [diff] [review]
Part2: raise compositor thread priority. v1

From comment 59, compositor thread is hardly scheduled.
This patch change compositor thread priority to -4 as v2.2 does.
Since dolphin is single core device, we should test app launch time and some heavy loading app performance(maybe video playback?) before landing to v2.1s.
Attachment #8592160 - Flags: review?(roc)
Comment on attachment 8592163 [details] [diff] [review]
Part1: apply occlusion culling

This patch would like to have Bug 1085223 and Bug 1113435 in v2.1s which were already in v2.2.
Dolphin device doesn't have a very powerful gpu. If we have too many pixels to draw, we would be block for a long time at glFinish().
Attachment #8592163 - Flags: review?(matt.woodrow)
Hi Vance and Shiwei,

For p1 patch:
Since we adjust the compositor priority, we might need to have some tests(maybe app startup time or some heavy-loading app) as [1] and [2].

For p2 patch:
We had some visual regressions(e.g. [3]) in v2.2 for this culling method. Please find someone to test this patch.

[1]
https://bugzilla.mozilla.org/show_bug.cgi?id=1071156#c13
[2]
https://bugzilla.mozilla.org/show_bug.cgi?id=1071156#c18
[3]
https://bugzilla.mozilla.org/show_bug.cgi?id=1113435#c0
Flags: needinfo?(vchen)
Flags: needinfo?(shiwei.zhang)
(In reply to Jerry Shih[:jerry] (UTC+8) from comment #79)
> Hi Vance and Shiwei,
> 
> For p1 patch:
> Since we adjust the compositor priority, we might need to have some
> tests(maybe app startup time or some heavy-loading app) as [1] and [2].
> 
> For p2 patch:
> We had some visual regressions(e.g. [3]) in v2.2 for this culling method.
> Please find someone to test this patch.
> 
> [1]
> https://bugzilla.mozilla.org/show_bug.cgi?id=1071156#c13
> [2]
> https://bugzilla.mozilla.org/show_bug.cgi?id=1071156#c18
> [3]
> https://bugzilla.mozilla.org/show_bug.cgi?id=1113435#c0

Thanks for your help Jerry!

Hi Shiwei, as Jerry mentioned, could you make a TB based on p1 patch and p2 patch, and then do some relevant tests? Probably the following scenarios:

1. startup time measurement for different applications to see if there is any significant regression
2. Check for UI display. Just play with some major application(messaging, gallery, music, email, etc) to see if you observe some UI display issues.

Hi Jerry, please let know if you think there is anything specific partner should test about

Thanks!
Flags: needinfo?(vchen) → needinfo?(hshih)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #80)
Yes, thanks, I'll do such test and inform our QA to pay more attention to regressions.
Flags: needinfo?(shiwei.zhang)
Comment on attachment 8592163 [details] [diff] [review]
Part1: apply occlusion culling

Review of attachment 8592163 [details] [diff] [review]:
-----------------------------------------------------------------

This is just an uplift of existing patches, right? We don't really need reviews for that.
Attachment #8592163 - Flags: review?(matt.woodrow) → review+
From https://wiki.mozilla.org/Release_Management/B2G_Landing#v2.1S ,
I don't find approval‑mozilla‑xxx flag for 2.1s, so I still request reviews for attachment 8592163 [details] [diff] [review] and attachment 8592160 [details] [diff] [review].

Please land attachment 8592163 [details] [diff] [review] and attachment 8592160 [details] [diff] [review] to gecko v2.1S.

Attachment 8592163 [details] [diff] is from bug 1085223 and bug 1113435.
Attachment 8592160 [details] [diff] is from bug 1071156.

2.1S try result:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c9579aee040b
There are some "C" tests failed due to some python script error, but I don't know why.
Keywords: checkin-needed
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #80)
> (In reply to Jerry Shih[:jerry] (UTC+8) from comment #79)
> > [1]
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1071156#c13
> > [2]
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1071156#c18
> > [3]
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1113435#c0
> 
> Thanks for your help Jerry!
> 
> Hi Shiwei, as Jerry mentioned, could you make a TB based on p1 patch and p2
> patch, and then do some relevant tests? Probably the following scenarios:
> 
> 1. startup time measurement for different applications to see if there is
> any significant regression
> 2. Check for UI display. Just play with some major application(messaging,
> gallery, music, email, etc) to see if you observe some UI display issues.
> 
> Hi Jerry, please let know if you think there is anything specific partner
> should test about
> 
> Thanks!

Test scenario in the [3], and then play with some high loading app(youtube, video or music?) to see whether we have significant affections for thread priority changing.
Flags: needinfo?(hshih)
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/8c8e50257ecf
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/5aa07347fff2
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-b2g-v2.1S: --- → fixed
status-b2g-v2.2: --- → unaffected
status-b2g-master: --- → unaffected
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.2 S10 (17apr)
Blocks: 1158670
No longer blocks: 1158670
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: