Try different glyph range scenarios

[yhahn]

OTOH:

• Current: based on unicode ranges
• Split into 256 char chunks
• Split into 1024 char chunks

I'll throw these in different prefixes on S3 for comparison and we can make llmr branches to try 'em out.

cc @kkaefer @mikemorris

[yhahn]

Available at:

http://mapbox.s3.amazonaws.com/gl-glyphs-256/{fontstack}/{range}.pbf
http://mapbox.s3.amazonaws.com/gl-glyphs-1024/{fontstack}/{range}.pbf

I rendered both of the current fontstacks:

• Open Sans Regular, Arial Unicode MS Regular
• Open Sans Semibold, Arial Unicode MS Regular

Here's gists with lists of the PBFs and sizes.

• 256: https://gist.github.com/yhahn/ff6d2087a29d7328b612
• 1024: https://gist.github.com/yhahn/b6ade7484c9b16844cc3

I can jump on setting up llmr branches to test these two different rangetypes out next.

cc @kkaefer @mikemorris

[yhahn]

@ansis I've pushed to both glyphs-256 and glyphs-1024 branches. I'm wondering how we want to actually make a decision here, like

• Some kind of timed load/render of map at X with cache busting querystrings
• Run this n times
• Compare ?

Better ways to do this?

cc @mourner

[mourner]

@yhahn we could run the same animation smoothly covering a range of zoom levels (with long duration so that tiles are loaded in time), one for 256 and one for 1024, cache busted, and compare total traffic (filtered in dev tools to only measure glyph pbfs).

[yhahn]

Just switched to 256 in llmr-native with good results. mapbox/mapbox-gl-native@9939647

Wondering if for now we should go with that? I am a bit skeptical of putting a lot of priority on a perf comparison today and trying to come up with very conclusive results that we won't want to reexplore later : )

[ansis]

256 sounds good for now

[mikemorris]

👍 to 256 for now, we may want to eventually do something like glyph ranges starting at the initial index of a unicode block and breaking in 256 glyph increments so that we don't randomly pull in unnecessary glyphs from nearby blocks. 1024 would be overkill for most blocks though.

[yhahn]

Great, we can refine/revisit/iterate on this after this cycle.

[yhahn]

Closing this down here -- will track further work upstream, e.g. mapbox/node-fontnik#36