992150 - [Tarako][Settings] Settings has a really slow response when restart it after being killed

Status: VERIFIED FIXED

(Firefox OS Graveyard :: GonkIntegration, defect, P2)

Description

[Bingqing Li]

Environment:
------------------------------------------------------
Gaia      32e15ec78cb245576a382468790d8f65461a5b3d
Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/e20c64a0ccd3
BuildID   20140403164001
Version   28.1
ro.build.version.incremental=eng.cltbld.20140403.201900
ro.build.date=Thu Apr  3 20:19:07 EDT 2014 


Steps to reproduce:
--------------------------------------------------------
1. Restart the device
2. Launch Settings
3. Scroll up/down
   --> The response is really slow, and sometimes cannot scroll
4. Wait for a while (maybe about 6 to 10 seconds)
   --> Can scroll up/down


Additional Info
--------------------------------------------------------
Meanwhile, it takes a long time (about 10 seconds) for some setting options to get ready, such as SIM manager,call settings messaging settings and Cellular & Date.

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

the system seems busy initializing the device. ni? Thinker for further comments
this seems to be a one time thing after restart of the device, let's not block on this for now. thanks

Comment 2

[Thinker Li [:sinker]]

Since launch time is ok, I don't think the latency of getting setting value is important for now since a lot values comes from HAL and drivers, their response time are quite unpredictable.

Comment 3

[Steven Yang [:styang]]

This should be an regression issue. It's much worse than the previous version. it's really too slow. re-nom.

Comment 4

[Peipei Cheng (needinfo if you need my action)]

Attachment: STR Video

I took a video for this. 
This is not a one time thing. We can consistently reproduce this on latest PVT build.
As you can see from the video.
Settings was launched for 5 times. It was killed by LMK once. And we can consistently see the unable-to-scroll problem.

Comment 5

[Bingqing Li]

Attachment: settings-logcat

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

base on the video, it looks like regression.1.3T+
Arthur can you please take a look? Thanks

Comment 7

[Arthur Chen [:arthurcc][inactive after 6/30]]

Hi Bingqing, is it possible to provide the build id of the last good build? Thanks.

Comment 8

[Bingqing Li]

(In reply to Arthur Chen [:arthurcc] from comment #7)
> Hi Bingqing, is it possible to provide the build id of the last good build?
> Thanks.

I'm not sure about the build id, but for what I can tell，we can always reproduce this issue on pvt build since Apr 1st 2014, and before that we used taipei build, 'Settings' was fine at that time.

Comment 9

[Arthur Chen [:arthurcc][inactive after 6/30]]

Thanks, Bingqing. The time you suggested matches what I suspected.

In bug 985928 we disabled APZ and which lead to scrolling performance issue. Without APZ enabled, loading scripts when launching settings app impacts the scrolling performance. I'll try to batch load the scripts to see if it makes improvements.

Comment 10

[Arthur Chen [:arthurcc][inactive after 6/30]]

The root cause is loading chinese fonts when displaying the carrier name for the STK item. I was wondering do we need to handle this corner case considering we currently may not ship the devices to areas where chinese is the default language?

Note that we should open another bug to track the performance issue when using chinese as the default language if necessary.

Comment 11

[Joe Cheng [:jcheng] (please needinfo)]

i don't believe chinese fonts is needed at this moment
ni? styang

Comment 12

[Steven Yang [:styang]]

No, we don't need Chinese at this moment.

Comment 13

[Arthur Chen [:arthurcc][inactive after 6/30]]

Per comment 12, can we resolve this bug as WONTFIX?

Comment 14

[Jason Smith [:jsmith]]

Hold up a second. Are these Chinese fonts included in the build? If so, why are they in tarako build if we aren't supporting it?

Comment 15

[Steven Yang [:styang]]

Hi Thomas, we don't need Chinese font in Tarako. please help to check it. Thanks

Comment 16

[thomas tsai]

kai-zhen, we can remove chinese fonts at this moment.

Comment 17

[Kai-Chih Hu [:khu]]

So, if my understanding is correct, we will remove Chinese fonts and reproduce this issue again. If it still happens, we will need someone to work on it.

Comment 18

[Joe Cheng [:jcheng] (please needinfo)]

to Kli to remove chinese font on tarako only

Comment 19

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: VID_0011.3gp

I verified with today build but I can't reproduce following comment 0. Setting can be srolled up/down as soon as it is launched.

Comment 20

[Bingqing Li]

(In reply to Kai-Zhen Li from comment #19)
> Created attachment 8406684 [details]
> VID_0011.3gp
> 
> I verified with today build but I can't reproduce following comment 0.
> Setting can be srolled up/down as soon as it is launched.

I noticed that you verified this issue without SIM card, am I right?

Please try to scroll up/down after inserting a SIM card of China Unicom.

After inserting a China Unicom SIM card, there should be an 'Operator Services' option at the bottom of 'Settings' page.

Comment 21

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: VID_0001.3gp

I can get same result when there is a SIM card. SIM stk is aslo loaded into setting correctly. My build info
--
Gaia      e72faa84340c7badd176659b35b7c45ad1a5a705
Gecko     8f7b2d03f04086f32fd842c225a757184df358c9
BuildID   20140414112012
Version   28.1
--

Bingqing, can you try if you can reproduce it in lastest build?

Comment 22

[Kai-Zhen Li [:seinlin][:kli]]

Complement to comment 21, I mean I can get the same result as my previous test in comment 19.

Comment 23

[Brogan Zumwalt [Inactive]]

On latest PVT build of 1.3T, issue reproduced 1 out of 10 attempts, and then only after first launch of settings app, after restarting device, for around three seconds before normal interaction resumes. Slight stuttering encountered even when issue does not reproduce. Single AT&T SIM card was used, "Operator Services" does not appear in Settings app.

Could not reproduce issue as shown in attachment 8406730 [details] from comment 21

1.3T Environmental Variables:
Device: Tarako 1.3T
BuildID: 20140415004002
Gaia: 44ff6248c28ff83b9ad1161847a176399f93d3bb
Gecko: 28aea220e338
Version: 28.1
Firmware Version: sp6821a

Comment 24

[Bingqing Li]

Attachment: repro-video

I can still reproduce this bug on build 20140415164003 with China Unicom SIM card. Pls see the attachment 'repro-video'.

Build Info:
-----------------------------------------------------
Gaia      c62bff0bfb8b069c962dfae2640e931cc9ad1bdf
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/7e764399b4fc
BuildID   20140415164003
Version   28.1
ro.build.version.incremental=eng.cltbld.20140415.201139
ro.build.date=Tue Apr 15 20:11:46 EDT 2014

Comment 25

[James Zhang (Spreadtrum)]

Does .woff font cause performance issue?

Comment 26

[thomas tsai]

Bingqing: do you have the other carrier sim cards? Does this happen only in China Unicom? Do you use single sim or dual sim? And If you use dual sims, what is in first slot and what's in the second? We can't repro this by Taiwan's "Chunghwa Telecom" sim card with traditional Chinese font.

Comment 27

[Bingqing Li]

(In reply to thomas tsai from comment #26)
> Bingqing: do you have the other carrier sim cards? Does this happen only in
> China Unicom? 
Not only in China Unicom, but also in CMCC (China Mobile Communication Corporation).

>Do you use single sim or dual sim? And If you use dual sims,
> what is in first slot and what's in the second? We can't repro this by
> Taiwan's "Chunghwa Telecom" sim card with traditional Chinese font.
I used dual sim, and both are China Unicom.


I also tried with single sim card. Here are the results:
------------------------------------------------------------------------------------------------
1.This can be reproduced with single CMCC sim card, no matter which slot the card is in.

2.This can be reproduced with single China Unicom sim car in the first slot.

3.The scrolling is fine with single China Unicom sim card in the second slot.


And I noticed that no matter which slot the CMCC sim card is in, "Operator Services" shows up in Settings app, and there are some simplified Chinese characters.

But with single China Unicom sim card in the second slot, "Operator Services" does not appear in Settings app.

Comment 28

[Bingqing Li]

Maybe the simplified Chinese font cause this issue.

Comment 29

[Arthur Chen [:arthurcc][inactive after 6/30]]

I am able to reproduce this with Chunghwa Telecom sim card. There is an obvious lag when scrolling.

Comment 30

[James Zhang (Spreadtrum)]

(In reply to Bingqing Li from comment #28)
> Maybe the simplified Chinese font cause this issue.

Please see http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=300264
Is it the same performance issue caused by Chinese font?

Comment 31

[[:fabrice] Fabrice Desré]

John, can you help us knowing if this font could cause slowdown? Is that similar to bug 921858 ?

Comment 32

[Peipei Cheng (needinfo if you need my action)]

(In reply to James Zhang from comment #30)
> (In reply to Bingqing Li from comment #28)
> > Maybe the simplified Chinese font cause this issue.
> 
> Please see http://bugzilla.spreadtrum.com/bugzilla/show_bug.cgi?id=300264
> Is it the same performance issue caused by Chinese font?

Yes, if SMS list contains some Chinese characters, the performance is also bad.

Comment 33

[John Daggett (:jtd)]

Assuming this is a bug specific to 1.3t, I'm not sure this is a font-related problem.  It's not at all clear from the comments here whether this is something specific to the particular set of fonts on the device or not.  If it's the default font for the device, a delay will likely occur in any app that uses that font, not just the Settings app.

I think someone should run the Gecko profiler and try and see where the Settings app is spending time at startup.  I think that will be much more productive than guessing what might be the cause.

Comment 34

[Kai-Zhen Li [:seinlin][:kli]]

Bingqing, 

I don't have a SIM card which STK includes simple Chinese.
Can you remove some fonts and then try again?

$ adb root
$ adb remount
$ adb shell
# rm /system/fonts/DroidSansFallback.woff /system/fonts/MTLc3m.woff /system/fonts/MTLmr3m.woff
# reboot

Then check if setting still has slow response.

Comment 35

[Arthur Chen [:arthurcc][inactive after 6/30]]

My result is not as bad as https://bugzilla.mozilla.org/attachment.cgi?id=8402157 shows. There is only 2~3 seconds lag on my device.

Comment 36

[Peipei Cheng (needinfo if you need my action)]

(In reply to John Daggett (:jtd) from comment #33)
> Assuming this is a bug specific to 1.3t, I'm not sure this is a font-related
> problem.  It's not at all clear from the comments here whether this is
> something specific to the particular set of fonts on the device or not.  If
> it's the default font for the device, a delay will likely occur in any app
> that uses that font, not just the Settings app.

Yes, it is true that other app was also affected. One example should be Messages.
The message list loading performance is worse when there is Chinese characters than when there is English only.

Comment 37

[Bingqing Li]

(In reply to Kai-Zhen Li from comment #34)
> Bingqing, 
> 
> I don't have a SIM card which STK includes simple Chinese.
> Can you remove some fonts and then try again?
> 
> $ adb root
> $ adb remount
> $ adb shell
> # rm /system/fonts/DroidSansFallback.woff /system/fonts/MTLc3m.woff
> /system/fonts/MTLmr3m.woff
> # reboot
> 
> Then check if setting still has slow response.

Tried with single China Unicom SIM card:
-----------------------------------------------------------------------------
After removing those fonts, scrolling is fine, but the stk does not show in settings, the welcome page of China Unicom does not show either. Is there anything wrong?


Tried with single CMCC SIM card:
-----------------------------------------------------------------------------
After removing those fonts, it's better than before, but still has about 2 seconds lag.
The stk shows in settings, but the Chinese characters can not be shown correctly.

Comment 38

[Steven Yang [:styang]]

de-flag due to we don't need Chinese now.

Comment 39

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: BN_ttf_vs_woff_browser.png

When font with around 100KB of size is used, it is hard to observe the different between ttf and woff.

Comment 40

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: CHT_ttf_vs_woff_settings.png

When font with large size is used, the difference between using ttf and woff is very significant. I think this is because the whole file of woff need to be extracted into RAM and introduce some delay and memory consumption. And this could also be the root cause of this bug.

Comment 41

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: Copy MOZ_PRODUCT_LOCALES related fonts only.

Michael, per comment 39 and comment 40, I think we should remove fonts for tarako. Do you think if this is reasonable?

Comment 42

[Jason Smith [:jsmith]]

(In reply to Steven Yang [:styang] from comment #38)
> de-flag due to we don't need Chinese now.

As I stated above, you need to remove this from the build. It's causing an unnecessary performance hit in the operating system. But you can't leave around something that doesn't work - that's going to leave behind a poor user experience for users making use of the build.

Comment 43

[John Daggett (:jtd)]

Whatever the slowdown is here, it needs to be profiled!!!!! Pulling out random fonts like Droid Sans Fallback (!!!) is *not* a solution.  Once we have a profile we can start to track down where the slowdown is and figure out a solution.  Trying random things to "solve" the problem will just end up wasting a lot more time.

Comment 44

[John Daggett (:jtd)]

Using the Gecko Profiler:
https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler

Comment 45

[John Daggett (:jtd)]

Guessing this is related to memory usage associated with WOFF packaging, bug 992150. May even be a dupe of that.

But profiling is needed to confirm that rather than guessing... ;)

Comment 46

[Peipei Cheng (needinfo if you need my action)]

Attachment: profile_1324.zip

John, I captured a profile. could you please take a look? Thank you very much!

Comment 47

[John Daggett (:jtd)]

(In reply to pcheng from comment #46)
> Created attachment 8408786 [details]
> profile_1324.zip
> 
> John, I captured a profile. could you please take a look? Thank you very
> much!

Hmmm, not much info in there. Only 700ms for the Settings app and there's a lack of symbols in the stack traces.  Guessing you didn't build with profiling enabled maybe?

Profiling build instructions:

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

Then, you need to run ./profile ps to get a list of running apps *before* running the Settings app.  Look for the process labeled "(Preallocated ...".  You want to profile that app and run Settings after that.  That will get you a profile of what happens when the Settings app starts up.

First get a list of app process id's:

./profile.sh ps

  PID Name
----- ----------------
  845 b2g              profiler not running
  893 (Nuwa)           profiler not running
  909 Homescreen       profiler not running
  937 Messages         profiler not running
 1024 (Preallocated a  profiler not running

Then, start profiling the "(Preallocated" process using its process id:

./profile.sh start -i 5 -f js,stackwalk -p 1024

Right after this, start the Settings app.  This should produce a profile which tells you what was going on during the Settings app startup.

If you have questions about this, maybe ask someone in the office who uses the profiler often?

Comment 48

[Arthur Chen [:arthurcc][inactive after 6/30]]

Ting has been working on font loading performance issues in bug 992346 and bug 997007. Ting, could you share your observations with us? Thanks!

Comment 49

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: profile_sym.tgz

Two profile of settings with different fonts.

With ttf font: profile_ttf_477_Settings.sym

With woff font: profile_woff_455_Settings.sym

Comment 50

[Ting-Yu Chou [:ting] (away)]

Attachment: profile settings launch with language chinese

Try set filter |FindFontForChar|.

Comment 51

[Ting-Yu Chou [:ting] (away)]

For attachment 8408872 [details], two huge fonts (woff) were found for some chars while launching Settings:

  MotoyaLMaru W3 mono (from WhichPrefFontSupportsChar(), ~0.46s),
  Droid Sans Fallback (from WhichSystemFontSupportsChar(), ~2.6s)

The uncompressed SFNT is not shared between processes, if changing font is not an option because of ROM size, probably we need some efforts on freetype2.

Comment 52

[Ting-Yu Chou [:ting] (away)]

BTW, I am not sure why WhichPrefFontSupportsChar() found Chinese characters from MotoyaLMaru, MotoyaLMaru is a Japanese font.

Comment 53

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: profile settings launch with ttf fonts

In the profile, I didn't see WhichPrefFontSupportsChar and WhichSystemFontSupportsChar as in comment 51.

Comment 54

[John Daggett (:jtd)]

Thanks Ting, this is exactly what was needed!!

http://people.mozilla.org/~bgirard/cleopatra/#report=faafa5c48375b39c276f43b805022cc389a1ef8f

Looks like a lot of time spent doing woff decompression:

gfxFontGroup::FindFontForChar == 27.9%
  woff_open_font              == 22.0%

From comment 52 it sounds like the content doesn't have the lang attribute set, so we're sort of flying blind within the font fallback code.

To confirm this, use textrun logging:

export NSPR_LOG_MODULES=textrun:5,textrunui:5 

This will log each textrun constructed so it's not something you want to leave enabled.  It'll produce log entries like the one below:

(textrun) fontgroup: [monospace] lang: ja-jp script: 25 len 82 weight: 400 width: 0 style: normal size:  32.00 1-byte TEXTRUN [ letterspacing-examples.html                            17-Jun-2013 16:00  3.7K  

The question is what's the lang setting for most of the Chinese content?  The lang is used to decide which font prefs to use and it will speed up the fallback font search if this is specified correctly.

Fallback for CJK content is tricky because we can't easily predict the right font based on the script, since Simplified, Traditional and Japanese share Han codepoints.  If the lang attribute is set, we'll try the fonts specified in the preferences first.  In the profile above, 13.5% of the time is spent within gfxPlatformFontList::CommonFontFallback.  This is called when pref fonts don't support a given character, so I'm guessing this occurs because the right pref font isn't getting picked up.  For most content, this should only rarely be called.

Comment 55

[John Daggett (:jtd)]

This appears to be a side effect of packaging fonts in WOFF format, since the Freetype code appears to be decompressing entire fonts rather than only selected tables.

Comment 56

[Ting-Yu Chou [:ting] (away)]

John,

I set language Chinese and launched Settings, listed only "Help" and its
translation "說明" below. I found:

  1. No matter lang is zh-tw or en-us, MotoyaLMaru is always found for 0x660e,
     is there a font searching order defined for specific language?
  2. Though I am not sure how locale is applied, but isn't the first textrun redundant? 
  3. For the 2nd and 3rd textrun, maybe keeps only 3rd one is enough, but
     probably setting document.documentElemnet.lang at navigator.mozL10n.ready
     callback is too late for this?

Please let me know if I should file another bug as this is a different topic
from original bug.

1074906248[40422080]: (textrun) fontgroup: [sans-serif] lang: en-us script: 25 len 4 weight: 400 width: 0 style: normal size:  19.00 1-byte TEXTRUN [Help] ENDTEXTRUN
gfxFontGroup::FindFontForChar aCh=0x00000048
gfxFontGroup::FindFontForChar aCh=0x00000065
gfxFontGroup::FindFontForChar aCh=0x0000006c
gfxFontGroup::FindFontForChar aCh=0x00000070
...
1074906248[40422080]: (textrun) fontgroup: [sans-serif] lang: en-us script: 17 len 2 weight: 400 width: 0 style: normal size:  19.00 2-byte TEXTRUN [說明] ENDTEXTRUN
gfxFontGroup::FindFontForChar aCh=0x00008aaa
1074906248[40422080]: (textrun-systemfallback-common) char: u+008aaa unicode-range: 31 script: 17 match: [Droid Sans Fallback] time: 47us cmaps: 0
gfxFontGroup::FindFontForChar #9 Droid Sans Fallback
gfxFontGroup::FindFontForChar aCh=0x0000660e
gfxFontGroup::FindFontForChar #7 MotoyaLMaru W3 mono
...
Calling navigator.mozL10n.ready() with callback, and the callback function of
navigator.mozL10n.ready() gets called, set document.documentElement.lang to "zh-TW".
...
1074906248[40422080]: (textrun) fontgroup: [sans-serif] lang: zh-tw script: 17 len 2 weight: 400 width: 0 style: normal size:  19.00 2-byte TEXTRUN [說明] ENDTEXTRUN
gfxFontGroup::FindFontForChar aCh=0x00008aaa
1074906248[40422080]: (textrun-systemfallback-common) char: u+008aaa unicode-range: 31 script: 17 match: [Droid Sans Fallback] time: 19us cmaps: 0
gfxFontGroup::FindFontForChar #9 Droid Sans Fallback
gfxFontGroup::FindFontForChar aCh=0x0000660e
gfxFontGroup::FindFontForChar #7 MotoyaLMaru W3 mono

Comment 57

[John Daggett (:jtd)]

(In reply to Ting-Yu Chou [:ting] from comment #56)
> John,
> 
> I set language Chinese and launched Settings, listed only "Help" and its
> translation "說明" below. I found:
> 
>   1. No matter lang is zh-tw or en-us, MotoyaLMaru is always found for
> 0x660e,
>      is there a font searching order defined for specific language?

Especially for common characters like this, you should always end up (1) using a pref font and (2) the pref font should follow the lang attribute.  You shouldn't be picking up a Japanese font at all.

Hmmm, looking over the code a little more closely, I suspect the code in gfxFT2FontGroup::WhichPrefFontSupportsChar is where the problem lies.  I'm also not sure why this code exists, it appears to be a dupe of the logic in gfxFontGroup::WhichPrefFontSupportsChar.  

I'll take a look at this tomorrow.  I suspect this is actually a separate bug, the main cause of the slowdown is probably the issue with loading large WOFF fonts (bug 997007).

Comment 58

[Kai-Zhen Li [:seinlin][:kli]]

Comment on attachment 8408291 [details] [review]
Copy MOZ_PRODUCT_LOCALES related fonts only.

Michael, woff could introduce memory usage and delay, especially when fonts with large file size is used. So I think it could be better to use ttf on tarako and use less fonts for ROM size issue. How do you think?

Comment 59

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: Disable COMPRESS_FONTS and define MOZ_PRODUCT_LOCALES

Comment 60

[John Daggett (:jtd)]

Comment on attachment 8409750 [details] [diff] [review]
Disable COMPRESS_FONTS and define MOZ_PRODUCT_LOCALES

Is this the correct product locale: bn-BD?

Comment 61

[Kai-Zhen Li [:seinlin][:kli]]

(In reply to John Daggett (:jtd) from comment #60)
> Comment on attachment 8409750 [details] [diff] [review]
> Disable COMPRESS_FONTS and define MOZ_PRODUCT_LOCALES
> 
> Is this the correct product locale: bn-BD?

John, yes it is mandatory.

Comment 62

[John Daggett (:jtd)]

Not bn_BD?

Comment 63

[Kai-Zhen Li [:seinlin][:kli]]

(In reply to John Daggett (:jtd) from comment #62)
> Not bn_BD?
Oh, actually I am not sure what is the difference between bn-BD and bn_BD. But bn-BD can be used as part of url to clone git repo, such as https://git.mozilla.org/releases/l10n/bn-BD/gaia.git

Comment 64

[James Zhang (Spreadtrum)]

We need bn_BD for Indian market, we don't need Chinese font.

Comment 65

[Michael Wu [:mwu]]

This bug only affects chinese locales, so I don't think this is a blocker. Testing should switch to locales relevant to the target market, and we should figure out how to make freetype handle woffs better, if it's possible.

Comment 66

[Jason Smith [:jsmith]]

(In reply to Michael Wu [:mwu] from comment #65)
> This bug only affects chinese locales, so I don't think this is a blocker.
> Testing should switch to locales relevant to the target market, and we
> should figure out how to make freetype handle woffs better, if it's possible.

See https://bugzilla.mozilla.org/show_bug.cgi?id=992150#c42.

Comment 67

[Michael Wu [:mwu]]

I read your comment. It's not causing a performance hit on any locale we care about.

Comment 68

[Jason Smith [:jsmith]]

(In reply to Michael Wu [:mwu] from comment #67)
> I read your comment. It's not causing a performance hit on any locale we
> care about.

That's why the bug is intending to remove the locales from the build. Otherwise, we'll end up shipping with locales that we don't intend to support that don't function properly.

Comment 69

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #68)
> (In reply to Michael Wu [:mwu] from comment #67)
> > I read your comment. It's not causing a performance hit on any locale we
> > care about.
> 
> That's why the bug is intending to remove the locales from the build.
> Otherwise, we'll end up shipping with locales that we don't intend to
> support that don't function properly.

We've also already gone through triage discussion multiple times already. This is reasking the same questions that we already answered. There's no point of renoming this bug on the basis of saying "we don't support this locale" - we already decided that was blocking here was to remove the unsupported locales.

Comment 70

[Michael Wu [:mwu]]

Fonts are part of full unicode support - on FirefoxOS, as a general policy, we support rendering all scripts regardless of the target locale. Unless we need to support CJK languages *better*, there's no reason to remove fonts.

Comment 71

[Jason Smith [:jsmith]]

(In reply to Michael Wu [:mwu] from comment #70)
> Fonts are part of full unicode support - on FirefoxOS, as a general policy,
> we support rendering all scripts regardless of the target locale. Unless we
> need to support CJK languages *better*, there's no reason to remove fonts.

This has already been answered multiple times. If it doesn't work, then remove it. We aren't shipping something that doesn't work. There's no excuse for purposely putting poor quality into the build.

Comment 72

[Jason Smith [:jsmith]]

mwu clarified this in person - we should just evangelize to partners to not using Chinese in their production builds & avoid testing the locale. We don't need to remove it.

Comment 73

[Kai-Zhen Li [:seinlin][:kli]]

Michael, partner update MOZ_PRODUCT_COMPRESS_FONTS := false in their repo, without the patch from attachment 8409750 [details] [diff] [review] system.img will larger than 105MB and it can can't be flashed correctly. This is only for v1.3t branch, if it is possible to get it merged. Thanks!

Comment 74

[Kai-Zhen Li [:seinlin][:kli]]

Marvin, can you give us some suggestion from the product point of view? Thanks!

Comment 75

[Marvin Khoo [:Marvin_Khoo]]

No we don't need Chinese front here, if it not work properly, please take it out if asap.

Comment 76

[Michael Wu [:mwu]]

(In reply to Kai-Zhen Li from comment #73)
> Michael, partner update MOZ_PRODUCT_COMPRESS_FONTS := false in their repo,
> without the patch from attachment 8409750 [details] [diff] [review]
> system.img will larger than 105MB and it can can't be flashed correctly.
> This is only for v1.3t branch, if it is possible to get it merged. Thanks!

Can you get it reverted then? This entire bug was never a real problem.

Comment 77

[Kai-Zhen Li [:seinlin][:kli]]

(In reply to Michael Wu [:mwu] from comment #76)
> 
> Can you get it reverted then? This entire bug was never a real problem.

I also think support all fonts is better. That's why we attempt to back port and use woff in v1.3t. But after using it for a period of time, test results tell us COMPRESS_FONTS is not good on tarako because it consumes all the memory we've shrunk in a lot of bugs and also introduce some delay when font with large size is selected to use. Before freetype get improved to handle woffs better, it is hard to convince partner revert back MOZ_PRODUCT_COMPRESS_FONTS := ture.

Comment 79

[Michael Wu [:mwu]]

(In reply to Kai-Zhen Li from comment #77)
> I also think support all fonts is better. That's why we attempt to back port
> and use woff in v1.3t. But after using it for a period of time, test results
> tell us COMPRESS_FONTS is not good on tarako because it consumes all the
> memory we've shrunk in a lot of bugs and also introduce some delay when font
> with large size is selected to use. Before freetype get improved to handle
> woffs better, it is hard to convince partner revert back
> MOZ_PRODUCT_COMPRESS_FONTS := ture.

Is this an actual problem in the locales we're interested in? If it is, I don't mind removing fonts for 1.3t, but if it's only in Chinese, then there's not much of a reason to remove fonts.

Comment 80

[Kai-Zhen Li [:seinlin][:kli]]

(In reply to Michael Wu [:mwu] from comment #79)
> 
> Is this an actual problem in the locales we're interested in? If it is, I
> don't mind removing fonts for 1.3t, but if it's only in Chinese, then
> there's not much of a reason to remove fonts.

Yes, this is an actual problem and it is also a common problem on tarako for all locales, beacause each app use malloc for woff font and the whole font file is extracted into memory. So memory used for fonts is not shared among apps. this is quite critical for meomory sensitive devices. But using ttf may cause ROM size issue, so having a flexible method to remove fonts is important and useful for our partner odm/oem.

Comment 81

[Michael Wu [:mwu]]

Per comment 80, it turns out this doesn't only affect Chinese. Chinese is just the most severely affected language.

Comment 82

[Marvin Khoo [:Marvin_Khoo]]

Hi Michael,
may i know what are we waiting here?

BR,
Marvin

Comment 83

[Joe Cheng [:jcheng] (please needinfo)]

hi mwu, can you please add more description on the 1.3T? nomination?
do you mean you want to add Chinese fonts back? and also apply compression?

the reason to not compress and take out chinese fonts is to have smaller system.img size so there are room for preloaded apps. thanks

Comment 84

[Kai-Zhen Li [:seinlin][:kli]]

What I understand form comment 81 is, compress font not only affect Chinese font on tarako but also other fonts. The affect on Chinese is the most significant one.

In my opinion, we should finish two things in this bug
1. Do not compress font, (It is done in partner side)
2. Provide a method to select and copy fonts when system.img is over size. (attachment 8408291 [details] [review] need to be reviewed and landed; or other patch which can provide similar function)

Comment 85

[Michael Wu [:mwu]]

(In reply to Joe Cheng [:jcheng] from comment #83)
> hi mwu, can you please add more description on the 1.3T? nomination?
> do you mean you want to add Chinese fonts back? and also apply compression?
> 
> the reason to not compress and take out chinese fonts is to have smaller
> system.img size so there are room for preloaded apps. thanks

Chinese fonts currently in the build. The request is the opposite - to remove compressing and fonts.

Comment 86

[Joe Cheng [:jcheng] (please needinfo)]

i wonder if this bug still exists if we have Chinese fonts included (but the fonts are not compressed?)
Thanks

Comment 87

[Michael Wu [:mwu]]

(In reply to Joe Cheng [:jcheng] from comment #86)
> i wonder if this bug still exists if we have Chinese fonts included (but the
> fonts are not compressed?)
> Thanks

No. But then the build fails because we can't fit the fonts in the partition.

Comment 88

[Joe Cheng [:jcheng] (please needinfo)]

there is a proposal to compress the fonts in /system partition so the image will fit but decompress the fonts to /data partition upon first boot up of the device (or first boot up after every factory reset), so the uncompressed fonts in /data can be used

Comment 89

[Steven Yang [:styang]]

Triage: 1.3T+

Comment 90

[Shian-Yow Wu [:swu]]

(In reply to Joe Cheng [:jcheng] from comment #88)
> there is a proposal to compress the fonts in /system partition so the image
> will fit but decompress the fonts to /data partition upon first boot up of
> the device (or first boot up after every factory reset), so the uncompressed
> fonts in /data can be used

Can we increase /system partition size and store uncompressed fonts in /system partition?

Comment 91

[James Zhang (Spreadtrum)]

I have landed kaizhen's patch on device/sprd and external/moztt.


commit 0b143c44e982b22905d999eb24b72a0e207579cd
Merge: c8c0759 b1b9aa1
Author: sprd-ffos <[e-mail]>
Date:   Tue May 6 20:59:53 2014 +0800

    Merge pull request #41 from Seinlin/bug-992150
    
    Bug 992150 - Copy MOZ_PRODUCT_LOCALES related fonts only.

Comment 92

[Rachel Pribble [:rpribble]]

Verified fixed on the Tarako v1.3T MOZ ril.

Environmental Variables:
Device: Tarako 1.3T
BuildID: 20140602014001
Gaia: 335486c42498fa7a93c21e4d6121199728602ab8
Gecko: 55e4d83019e5
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-4-29

Able to immediately scroll settings normally.