optimize glyph usage for offline

[jfirebaugh]

Currently, the first time an offline region is created for a particular style, we download all glyph ranges for all font stacks in the style. Offline resource sharing ensures that future offline regions with the same style reuse these glyphs.

Downloading only the glyph ranges actually used by visible features in the region would require parsing every downloaded tile, iterating over every feature, extracting the property values that might be rendered as text, and accumulating a set of used glyphs.

That seemed like a non-starter to me both in terms of the processing overhead for the thousands or tens of thousands of tiles in an offline download, and in the complexity it would add to the offline implementation, which was (and is) under severe time pressure.

While I don't see the current strategy changing for changing for v1 of offline, we should consider future optimizations that lower the glyph overhead for the initial region.

[mikemorris]

Possible implementations to reduce glyph overhead:

• Map character frequency to bounding box using a tool like https://github.com/tmcw/osm-rune to estimate necessary glyph ranges.
• Unbundle the C++ core from node-fontnik and:
  • Download full font files to process glyphs on the fly
  • Render glyph SDFs from device/system fonts

[mourner]

This is probably a throwaway idea but mentioning it anyway: we could add an optional field to the top-level Tile pbf message (or Layer) with a packed array of numbers representing glyph ranges required by that tile. This would require some additional code in mapnik-vector-tile, and would possibly need a minor spec version change to add this field. But there are pros:

• Adding this info when baking tiles is cheap
• We'll save a ton of bandwidth on offline glyphs
• The solution avoids the complexity of using a bbox-based API
• No additional requests necessary
• If the field is present, the client can start fetching glyph tiles before we completed parsing the whole vector tile

[jfirebaugh]

Per chat with @mikemorris and @yhahn, the approach we'd like to take is to give mbgl more smarts about which set of fonts should be considered "fallbacks" (e.g. "Arial Unicode Regular"), and then either ship a set of glyph SDFs for these fallbacks with the SDK, or for cases where shipped SDK/app size is at issue, download and pre-cache this set at runtime.

Then glyph requests (both offline and online) could be smart about splitting any given fontstack [A, B, ..., F, G] into a prefix of non-cached [A, B, ...] and a suffix of pre-cached [..., F, G] fonts. It would request glyph SDFs for [A, B, ...] at runtime, and composite the result with the cached SDFs for ..., F, G. This "compositing" would be entirely on a glyph SDF level -- no SDF rendering machinery would be required.

[brunoabinader]

ship a set of glyph SDFs for these fallbacks with the SDK

This idea looks great. I believe this could help (1) solving the initial waiting period for labels to appear on places e.g. using CJK characters and (2) greatly reducing bandwidth usage for common data. Do we have numbers of how much space is required for our glyph set?

[dpieri]

Related to this, we've been seeing 404 responses on certain glyph ranges from the Mapbox API. One 404 will kill the offline download, so this issue increases the likelihood that an offline download will fail.

This font works

But this one does not.

Right now our offline downloads are failing 100% of the time because of these font 404s.

Edit: That font API url is no longer responding with a 404. The larger issue of a single bad font stopping the offline download process still remains.

[1ec5]

@dpieri, does the 404 still reproduce for you? We had a server configuration issue recently (related to rate limiting) that perhaps triggered these errors. You're right that errors like this shouldn't bork the download, though.

[dpieri]

@1ec5 I'm not seeing a 404 on that specific resource anymore. In general the download process has been a bit mysterious. Yesterday evening I found that after clearing our app's data and cache (via the Android app settings menu) downloads would fail on 404s regularly unless I proxied through my laptop to figure out what was 404ing. It seems to be working better now, but because of the weird behavior with the proxy I can't tell you which asset was 404ing.

[mkv123]

Currently downloading an offline region is about 73MB of fonts and then 1MB of actual vector data. Is there a workaround to reduce the static overhead of offline data caused by the fonts?

[hhartz]

Being able to ship these resources alongside the app instead of downloading would significantly improve the user experience for end users, as the initial download in most cases is so slow that users think something is wrong.

[ChrisLoer]

#11561 proposes the partial solution of allowing offline downloads to exclude CJK glyphs when local CJK glyph generation is supported.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[brunoabinader]

I think this idea is worth reconsidering - we might end up saving a lot on the offline cache size!

[stale]

This issue has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[LeeroyDing]

Is there a workaround for it?