User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20140623030201 Steps to reproduce: scroll the homescreen Actual results: it appears not smoothly, the display effect is worse than flame Expected results: it appears smoothly when scroll the homescreen.

Hi Vance: This problem is very important to our PTR review, please help to assign someone to investigate this problem.

Hi Yong Ren - Could you provide a video to demonstrate the performance difference between Flame and 7715 2.1? Thanks

Hi Vance: you can refer to the link ftp://ftp.spreadtrum.com/for_sprd_mozilla/ to get the mozilla_1141047.MOV in the video, the left one is 7715 , the right is flame.

(In reply to yong.ren from comment #3) > Hi Vance: > > you can refer to the link > > ftp://ftp.spreadtrum.com/for_sprd_mozilla/ > > to get the mozilla_1141047.MOV > > in the video, the left one is 7715 , the right is flame. Hi Vance: if you can not get it from the above link, you can also get the video from http://pan.baidu.com/s/1c0bCWXM

Thanks, i just saw the video. Could you let me know the configuration of Flame? if it is still running with dual core and 1G RAM, could you use software configuration to limit it to single core and 512MB RAM? Thanks

Hi Vance: we have already limited the flame to the single core, so do the flame device in the video.

Need QA's help on this. will need the fps data as well

Reproduce video upload here: https://www.youtube.com/watch?v=q9r0pZ4M7-M&feature=youtu.be Thanks

The average FPS of scrolling homescreen from my device is 41 with below build 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

(In reply to Mike Lien[:mlien] from comment #9) > The average FPS of scrolling homescreen from my device is 41 with below build > 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 Hi Mike, do you happen to have the fps data of Flame 2.1? Thanks

Sorry for the lost of Flame's result, the average FPS of scrolling homescreen is 56 with single core Flame v2.1 512MB 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

Hi Mike, our sprd RDs also want to test the FPS data, could you please tell us how to test it, thanks

You can enable the debug HUD from Seetings app -> Developer -> Developer HUD -> "Frame per second" After you enable it you can find there have three numbers on top left of screen. The left number indicates current FPS. More detailed you can refer to https://developer.mozilla.org/zh-TW/Firefox_OS/Debugging/Developer_settings

I know this FPS developer settings, but when we scroll the homescreen ,it always change rapidly, how do you get the average fps? thanks .

Since one FPS is already an average value and we only want to do furthur average of the variation during scrolling. I record 10 numbers while homwscreen is scrolling and drop the beginning and ending numbers.

Another way is to modify gecko to let FPS can show on logcat directly then average it.

Hum 41 is really bad...Hi Steven, might need your help here, as I remember we at least have 55 fps while doing most of the operation on 1.3T, now with better CPU and more RAM, it is strange that the performance downgrade so badly. Could you help to find someone to check this one as well as Bug#1141053 ? This two are not blocking PTR2 but will block PTR3, so we better start to check earlier Thanks

ni Shawn as well to put this one under his radar

Vincent, need your help to work on this. Also put Peter in the cc list.

I tried to dump systrace to compare for both dolphin and flame_v2.1, I saw there is a timing difference on Compositor thread. Please observing the keyword "CompositorParent::Composite" in the attached file. In dolphin, it may take above 30ms while flame_v2.1 only take about 10ms.

More narrowing down the code, there are two function call taking about 10~20 ms. [1]:https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/file/cb5d3db6ef48/widget/gonk/libdisplay/GonkDisplayJB.cpp#l207 mFBDevice->compositionComplete(mFBDevice); [2]:https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/file/cb5d3db6ef48/widget/gonk/libdisplay/GonkDisplayJB.cpp#l227 return !mFBDevice->post(mFBDevice, buf); We need partner's support to figure it out for FB device.

Hi vincent: i use gdb to debug the code you mention in comment23, when I scroll the homescreen, it doesn't break at this two positions. I don't konw why, can you help to explain, thanks. ps: I can't open attachment 8577909 [details] through the firefox or chrome, could you tell me how to open it.

(In reply to yong.ren from comment #24) > Hi vincent: > > i use gdb to debug the code you mention in comment23, when I scroll the > homescreen, it doesn't break at this two positions. > > I don't konw why, can you help to explain, thanks. > Did you try to add print message to make sure it? > ps: I can't open attachment 8577909 [details] through the firefox or > chrome, could you tell me how to open it. The attached systrace can only open in Chrome browser. Maybe you need update the newer version of bowser to open it.

Hi vincent: I add log to these codes, the result is when I boot the phone, the log print a lot about "GonkDisplayJB::Post", but when i scroll the homescreen ,the log can not print any more.

ni Danny as well to see if he has any thoughts on this one

(In reply to yong.ren from comment #26) > Hi vincent: > > I add log to these codes, the result is > > when I boot the phone, the log print a lot about "GonkDisplayJB::Post", > but when i scroll the homescreen ,the log can not print any more. I always see the log print when scrolling hte homescreen.

Hi Yong Ren - Per Comment#28, could you help to try again to see if indeed the log won't print when you scroll the homescreen? Thanks

Hi vance: I just did it for some times, and the log still can not print anything. Hi vincent: the following is the log I add, please help to check if something is worong? and if you can always see the log print when scrolling the homescreen, could you help to provide the gdb trace when call this method. thanks a lot. diff --git a/widget/gonk/libdisplay/GonkDisplayJB.cpp b/widget/gonk/libdisplay/GonkDisplayJB.cpp index 7b540f9..6f4bb7f 100644 --- a/widget/gonk/libdisplay/GonkDisplayJB.cpp +++ b/widget/gonk/libdisplay/GonkDisplayJB.cpp @@ -25,12 +25,16 @@ #include <hardware/hwcomposer.h> #include <hardware/power.h> #include <suspend/autosuspend.h> +#include <android/log.h> · #if ANDROID_VERSION == 17 #include "GraphicBufferAlloc.h" #endif #include "BootAnimation.h" · + +#define LOG(args...) __android_log_print(ANDROID_LOG_INFO, "yong GonkDisplayJB--> ", ## args) + using namespace android; · namespace mozilla { @@ -203,7 +207,9 @@ GonkDisplayJB::SwapBuffers(EGLDisplay dpy, EGLSurface sur) // Only HWC v1.0 needs this call. // HWC > v1.0 case, do not call compositionComplete(). // mFBDevice is present only when HWC is v1.0. + LOG("SwapBuffers In"); if (mFBDevice && mFBDevice->compositionComplete) { + LOG("mFBDevice composition"); mFBDevice->compositionComplete(mFBDevice); } · @@ -221,9 +227,11 @@ GonkDisplayJB::SwapBuffers(EGLDisplay dpy, EGLSurface sur) bool GonkDisplayJB::Post(buffer_handle_t buf, int fence) { + LOG("Post medthod In"); if (!mHwc) { if (fence >= 0) close(fence); + LOG("Post medthod mFBDevice post"); return !mFBDevice->post(mFBDevice, buf); }

This is the way I added. diff --git a/widget/gonk/libdisplay/GonkDisplayJB.cpp b/widget/gonk/libdisplay/GonkDisplayJB.cpp index 7b540f9..04ed73b 100644 --- a/widget/gonk/libdisplay/GonkDisplayJB.cpp +++ b/widget/gonk/libdisplay/GonkDisplayJB.cpp @@ -224,6 +224,7 @@ GonkDisplayJB::Post(buffer_handle_t buf, int fence) if (!mHwc) { if (fence >= 0) close(fence); + ALOGE(" GonkDisplayJB::Post entry "); return !mFBDevice->post(mFBDevice, buf); }

Similar conclusion as comment 22. I profiled scrolling at homescreen on v1.4 on dolphin 256MB and 512MB devices, I found "CompositeToTarget" spent more time on 512MB dolphin device. In 256MB dolphin, there are 4 of 25 times that CompositeToTarget time are around 30ms. In 512MB dolphin, half of CompositeToTarget time are around 30ms.

Hi Yong.Ren - Could you follow Vincent's approach in Comment#31 to add logs? Thanks

And Danny, so is it relevant to RAM size? or do you know who can help to further look into CompositeToTarget?

(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #36) > And Danny, so is it relevant to RAM size? or do you know who can help to > further look into CompositeToTarget? I don't think it related to RAM size, but I guess it might relate to other components which will impact I/O performance. Hi Siiaceon, do you have any idea regarding this difference? It might relate to different hardware.

Hi vance: I checked it again follow the comment 31, but we still can not see any log with GonkDisplayJB

Hi danny: I test it on both both 256M dophin device (7715 ga), the first one is use 2.1s gecko and 1.4 gaia and the second is use 1.4 gecko and 1.4 gaia. and when we scroll the settings list, we find that the second one is more smoothly than the first one. cause the gonk and gaia we used is same, so we think its the 2.1 gecko modify leads to this problem. what do you think about it?

(In reply to yong.ren from comment #39) > Hi danny: > > I test it on both both 256M dophin device (7715 ga), > > the first one is use 2.1s gecko and 1.4 gaia > > and the second is use 1.4 gecko and 1.4 gaia. > > and when we scroll the settings list, we find that the second one is more > smoothly than the first one. > > > cause the gonk and gaia we used is same, so we think its the 2.1 gecko > modify leads to this problem. > > > what do you think about it? I think there are two conclusions by my analysis: 1. v2.1 consume more CPU usage 2. 512MB device got worse performance than 256MB devices. (see comment 34)

Hi danny: Though my analyze with CompositorParent and Touch event, I think this problem may be caused by the following two reasons: 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. should we upgrade the compositor thread priority to imporve it?

(In reply to yong.ren from comment #41) > Hi danny: > > Though my analyze with CompositorParent and Touch event, I think this > problem > may be caused by the following two reasons: > > 1. Touch event process are spending more cpu in v2.1 than v1.4. (may be > related with APZ mechanisim). Could you disable APZC and update the test result? > > > 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. > > should we upgrade the compositor thread priority to imporve it? Hmm, I try to change the priority higher but I cannot, maybe need to change cgroup or other setting. But I don't think it's a good solution, it just a test to determine the direction. Hi vliu, How is your comment about increase the priority of compositor?

Hi yong.ren, (In reply to Danny Liang [:dliang] from comment #42) > (In reply to yong.ren from comment #41) > > Hi vliu, > How is your comment about increase the priority of compositor? I don't think changing priority of compositor is a good way to go since texture update is in progress between main thread and compositor thread. If you use the keyword "CompositorOGL::EndFrame" to compare the time period in systrace file I attached for both flame and dolphin, you can easily find dolphin consumes more time than flame. Please also see Comment 22 and Comment 23 to know my following observation. I think you should focus on this part to improve it.

Hi vincent: cause our v1.4 use the same gonk, and its fps can reach 50 in most time; but in v2.1, fps can only reach 30 in most time, so we think that the 2.1 gecko is spending more cpu time when scroll the homescreen, and we doubt the touch event process cost more time in main thread than 1.4, and also because main thread has higher priority than the compositor thread, I suggest we should upgrade the compositor thread the higher priority to test if we can improve the fps. what do you think about it?

(In reply to yong.ren from comment #44) > Hi vincent: > > cause our v1.4 use the same gonk, and its fps can reach 50 in most time; > but in v2.1, fps can only reach 30 in most time, > so we think that the 2.1 gecko is spending more cpu time when scroll the > homescreen, > and we doubt the touch event process cost more time in main thread than > 1.4, and also > because main thread has higher priority than the compositor thread, > I suggest we should upgrade the compositor thread the higher priority to > test if we can improve the fps. > > what do you think about it? Can you please try Viral's suggestion in Bug 1120949? It may have performance improvement. https://bugzilla.mozilla.org/show_bug.cgi?id=1120949#c48

It seems that bug 1141053 has similiar problem I mentioned in Comment 22. https://bugzilla.mozilla.org/show_bug.cgi?id=1141053#c60

Yes, we analyze that bug 1141053 and this bug is the same problem.

I think Bug 1141053 Comment 63 also point out the problem I mentioned in Comment 22. https://bugzilla.mozilla.org/show_bug.cgi?id=1141053#c63

Okay, thanks vincent, I will investigate these two points quickly.

two calls related in gonk 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();

(In reply to yong.ren from comment #47) > Yes, we analyze that bug 1141053 and this bug is the same problem. Calling this fixed by bug 1141053 then. Given that v2.1s is EOL now, I don't think it's likely anything else is going to happen here anyway.

Excluding this in our queries as we don't have 2.1S device.