No description provided.
Please try with this patch.
Whiteboard: [c=progress p= s= u=tarako] [tarako] → [tarako]
After trying out the patch with Thinker, we have not found and visible performance gain. Ting-Yu, please find Thinker and try to figure out the detail. Thanks!
Assignee: alive → tchou
Confirmed with Tim and Lawrence the image was checked out and built today. I'll see what can I find from recent commits.
Tim, I can't simply flash raw gaia v1.3 (from https://git.mozilla.org/releases/gaia.git) to Tarako, it complains the disk space is not enough. So I'd like to double confirm the steps you used for flashing gaia this morning. # If the updating is failed, the screenshot will be kept disabled in windowClosed(). # There are three extra directories (gaia/customize_apps, gaia/local_mk, gaia/sprd_recource) from spreadtrum in my tree to drop unused applications.
Please flash Gaia apps to /data/local partition by using the following command: GAIA_INSTALL_PARENT=/data/local make install-gaia To purge any Gaia files first, do GAIA_INSTALL_PARENT=/data/local make reset-gaia Append |APP=system | before the command will only push the app zip, and save some time. The sprd* files are not related to this bug because they will not modify system app in any way. Thanks!
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #5) I see, will try this after back from holiday. > Please flash Gaia apps to /data/local partition by using the following > command: > > GAIA_INSTALL_PARENT=/data/local make install-gaia > > To purge any Gaia files first, do > > GAIA_INSTALL_PARENT=/data/local make reset-gaia > > Append |APP=system | before the command will only push the app zip, and save > some time. > > The sprd* files are not related to this bug because they will not modify > system app in any way. > > Thanks!
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #2) > After trying out the patch with Thinker, we have not found and visible > performance gain. > > Ting-Yu, please find Thinker and try to figure out the detail. Thanks! Tested on Tarako to figure out why Tim could not reproduce the high sys loading when back to home screen (screenshot is taken in windowClosed()): gaia (system app) - 22bc6be5 The launched app has chances to survive for more than 3 seconds (13/20) after back to home screen: 5/13: sys loading is high during the period and drops after it is killed 8/13: sys loading keeps low - b0aa7461 The launched app is killed (20/20) right after back to homescreen. # gecko = cd8bc54e # Usage is not running. # Number of major page faults goes up to over 100/second when sys loading is high.
blocking-b2g: --- → 1.3T?
Priority: -- → P2
Whiteboard: [c=progress p= s= u=tarako]
triage: not needed for tarako at this moment
blocking-b2g: 1.3T? → -
Status: NEW → ASSIGNED
Whiteboard: [c=progress p= s= u=tarako] → [c=progress p= s= u=]
kernel = 5727a193 gecko = 6ae23596 gaia = 19a5035b Based on the code above, I couldn't see high system loading from taking a screenshot while switching from app to home screen. Do we still need the patch (attachment 8365829 [details] [review]) which moves screenshot taking from windowClosed() to closeWindow()? # bug 963268 changed screenshot to a software canvas.
I think we can close this for now. We are no longer instantiating the GL stack in the content process which caused the high load and GPU contention.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Whiteboard: [c=progress p= s= u=] → [c=progress p= s=2014.02.28 u=]
Target Milestone: --- → 1.4 S2 (28feb)
You need to log in before you can comment on or make changes to this bug.