New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 763963 link

Starred by 3 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug



Sign in to add a comment

Freetype Data can cause font cache to grow beyond expected limits

Project Member Reported by ericrk@chromium.org, Sep 11 2017

Issue description

When Skia's glyph cache encounters a font it needs to handle, it creates FT_Face data using freetype and keeps that data cached until there are no further references. See: https://cs.chromium.org/chromium/src/third_party/skia/src/ports/SkFontHost_FreeType.cpp?sq=package:chromium&l=330

While this makes sense in general, the FT_Face data can be quite large (potentially MBs). Despite this, the size of FT_Face data is not currently estimated or counted. This means that the limits imposed on the glyph cache do not take into account the FT_Face data that is being kept alive.

This can be a problem, especially on low-end devices where memory is very limited.

To mitigate this, we may want to consider:
- Counting/estimating the size of FT_Face data and including this in the Glyph Cache's eviction strategy.
- Disabling web fonts on ultra-low-end devices (If web fonts are the culprit).

For an example of a problematic site, see: instagram.com/badgalriri
 
Labels: -Pri-2 Pri-1
Status: Untriaged (was: Available)
Bumping to priority 1, due to current focus on reducing memory on constrained
devices.

Emil, could someone take this bug?

Comment 2 by ericrk@chromium.org, Sep 11 2017

Cc: mariakho...@chromium.org dskiba@chromium.org
Labels: LowMemory

Comment 3 by e...@chromium.org, Sep 13 2017

Owner: bunge...@chromium.org
Status: Assigned (was: Untriaged)
Estimating/reporting the size would fall on skia as blink has knowledge of FT_Face.

Disabling webfonts on the other hand would be a blink feature.

Ben, could you comment on the feasibility of exposing the size of FT_Face?
Exposing the size of the data hanging off an FT_Face would be up to FreeType, which I don't think currently has any means of doing so. On the other hand, we could try manually tracking, by creating a separate FT_Library for each FT_Face and creating the FT_Library with a FT_Memory which keeps track of total allocation. So in theory this is possible, but it would require a bit of work as well as additional (memory) overhead.
Sounds like it would be a bit of work to accurately track webfont size. On the other hand, I assume that disabling WebFonts wouldn't be too hard. Do we have any UMAs or other metrics to help understand how often WebFonts are used on mobile sites?
Ping for bungeman

Comment 7 by hcm@google.com, Dec 5 2017

Owner: ----
I don't think Ben is the right person to answer the WebFonts/UMA question, more for Blink/Chrome (?) he's also out on leave, maybe checking in some...
Status: Available (was: Assigned)

Comment 9 by hcm@chromium.org, Jan 10 2018

Cc: hcm@chromium.org
Components: -Internals>Skia
Owner: e...@chromium.org
Status: Assigned (was: Available)
eae@, can you help answer the UMA/metrics question from #5 (or do you know who would know this?).

Comment 11 by e...@chromium.org, Jan 31 2018

Components: -Blink>Fonts Blink>WebFonts
Owner: ----
Status: Untriaged (was: Assigned)
Hi, the webfonts team should know, reassigning.
Hi Web Fonts team, can you please help us here?
Cc: ksakamoto@chromium.org
WebFont.WebFontsInPage UMA tracks the number of web fonts used in a page.
On Android, ~7% of the page loads have at least one web font.

Comment 15 by ojan@chromium.org, May 8 2018

Cc: -ojan@chromium.org

Sign in to add a comment