Testing glyph rendering capacity for CJK fonts

[amyleew]

To test glyph texture size (currently 1024x1024) to ensure it's large enough to render a kind of "worst case scenario" (that is still realistic) china mapview. We're simulating stress tests of displaying CJK characters.

@xrwang and I worked on the inital rendering test which maxed out point and character density, and it failed, as expected. The second test case should reflect what could realistically represent the text diversity/density of a china map view.

Setup

• Install GL JS
• Run the render test suite and run it targeting a specific test (https://github.com/mapbox/mapbox-gl-js/blob/master/CONTRIBUTING.md#running-tests)
• Check out the first test
  • cjk-fonts/literal/style.json
  • cjk-fonts/literal/expected.png
• Pull china-test branch of the GL test suite repo & npm link it into place with GL JS
• Craft a glyph overflow test. Suggestions:
  • Use an inline geojson source (https://github.com/mapbox/mapbox-gl-test-suite/blob/master/render-tests/geojson/inline-feature/style.json)
  • You'll probably want to script the creation of your inline geojson. E.g. something that iterates through N CJK characters, creates a point per character randomly within the render test viewport'

In theory there should be a test that should push GL JS to its very limit of glyph atlas space. Then we'll want to see if native can pass the test (probably not, GL Native should behave exactly like GL JS) and work toward parity. (per @yhahn)

Background

• Allow arbitrarily many glyphs and sprites to be used in a style mapbox-gl-js#141

Next steps

• Estimate count of distinct glyphs in text dense location on the baidu map
• Craft a test(s) to simulate this density

@mapbox/cartography-cats

[bhousel]

To test glyph texture size (currently 1024x1024) to ensure it's large enough to render a kind of "worst case scenario" (that is still realistic) china mapview. We're simulating stress tests of displaying CJK characters.

1024x1024 is not large enough to render a "worst case scenario".. You can load a lot of glyphs at z10, and 60degree tilt to load more tiles on the screen, then pan around a little bit.

see mapbox/mapbox-gl-js#1923 (comment)

"I have been testing around this location in Southern China: # 10.01/22.9452/113.1932 - set tilt to maximum to load as many tiles as possible, and scroll around. It does take a LOT of scrolling to get to 2048x2048, and even textures larger than that are considered safe for WebGL."

[amyleew]

Results

These two tests for character count rendering used Chinese Streets data on a sample map, only plotting road labels, pois, and place_labels. Tests are both passing possibly because the range of 700 or 1350 characters are not solely Chinese characters. The Noto CJK SC font contains all four languages characters: S Chinese, T Chinese, Japanese and Korean and the languages are mixed together in the unicode range as well.

Test 1

Test 1 used generated bbox-test1.geojson with roughly 86 points testing about 700 characters.

Test 2

Test 2 used generated bbox-test2.geoson with roughly 139 points and 1350 characters.

Next steps

Instead of grabbing the assumed range of Chinese characters, like I did with these tests... Test 1 was 385 to 1085 and Test 2 was 385 to 1735 .... @xrwang and I are looking to approach this differently and either find reliable way to only test Chinese characters, possibly using online sources for CJK table data. Then run the two tests again with only Chinese characters being rendered.

Or, can we change the way gl makes that spritesheet of glyphs / the glyph atlas? Maybe it doesn't make sense to grab the 256 characters surrounding the character when working with non-Latin fonts? If that is even an option.

/cc @yhahn

[xrwang]

echoing @amyleew's comment, we're finding the unicode ranges for cjk, and just SC (simplified chinese) are bit complicated.

We want to figure out if, on GL / fontnik, when the font stack goes from pbf ---> sdf ---> texture, it can be selective aka we can have more control over which characters end up on the glyph texture. From tests / the way the table is arranged, https://en.wikipedia.org/wiki/List_of_CJK_Unified_Ideographs,_part_1_of_4 since the numerical sequence is by radical and not by frequency of use, we actually don't need entire ranges of characters from the font, only intermittent ones. Ie, instead of putting an entire range of characters, 0-6000 on the glyph texture, could the current set up work with putting 0-40, value 1000, value 1234, value 1568, etc ?

[friedbunny]

“Frequency of use” may be a deceiving metric if it’s based on written-use, rather than use in place names. In Japan, at least, there are places that use very uncommon characters in their names.

I couldn’t find a good list of rare-character names, but this list has some discussion of unusual place name readings and bit on the use of obsolete, non-jōyō kanji.

[amyleew]

Glyph atlas

Per chat w/ @nickidlugash @xrwang, we're looking to examine the glyph atlas itself. The entire atlas can fit up to 1024 characters based on my test China map, I counted about 900 CJK characters on a full glyph atlas.

I was able to get a 900 test passing with a slight diff, but I'd like to test these geojson files in Studio to compare the glyph atlas files they produce.

Next steps

Take these tests into Studio to visualize the glyph atlas and see:

1. When the atlas fills up
2. What it does / how it renders when the atlas is full

[mikemorris]

We want to figure out if, on GL / fontnik, when the font stack goes from pbf ---> sdf ---> texture, it can be selective aka we can have more control over which characters end up on the glyph texture.

@xrwang @friedbunny The only glyphs that should end up in the glyph atlas are those that will actually be needed to render labels - we may download many more glyph ranges because of the way we split glyph ranges into PBFs, but that's a separate problem from glyph atlas overflow, one I started exploring a while ago in mapbox/node-fontnik#36

The glyph "atlas" is just a 1024x1024 image, so the exact number of glyphs it fits may vary depending on the size of the glyph (' will likely take up less space than A) and the packing algorithm (the blank space at the end of the 3rd and 5th lines in the image ^ could possibly be used more efficiently if the glyphs were placed differently or happened to be added in a different order).

[bhousel]

Yes, echoing everything @mikemorris said above... Also the actual atlas texture layout can depend on which tiles happen to load before which other tiles. (This happens asynchronously).

[lucaswoj]

Closed by #131