-
Notifications
You must be signed in to change notification settings - Fork 1.3k
[core] Don't overwrite locally renderable glyphs with remote glyphs #15407
Conversation
90ec5d3
to
258468d
Compare
@@ -99,8 +99,10 @@ void GlyphManager::processResponse(const Response& res, const FontStack& fontSta | |||
|
|||
for (auto& glyph : glyphs) { | |||
auto id = glyph.id; | |||
entry.glyphs.erase(id); | |||
entry.glyphs.emplace(id, makeMutable<Glyph>(std::move(glyph))); | |||
if (!localGlyphRasterizer->canRasterizeGlyph(fontStack, id)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have similar check inside GlyphManager::getGlyphs()
, so that we request only the ranges that cannot be rasterized locally. How would it be possible to have locally rasterizable glyphs in the response?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few cases where the 256 glyph range includes glyphs that are locally rasterizable and remotely fetched.
In such a range, when a glyph is fetched from the remote request, processResponse
will currently add it to the entries
table.
A subsequent call to getGlyphs
will correctly pass the canRasterizeGlyph
check, but will return the glyph that was previously written into entries
by processResponse
.
mapbox-gl-native/src/mbgl/text/glyph_manager.cpp
Lines 35 to 38 in 5d1ed5d
if (localGlyphRasterizer->canRasterizeGlyph(fontStack, glyphID)) { | |
if (entry.glyphs.find(glyphID) == entry.glyphs.end()) { | |
entry.glyphs.emplace(glyphID, makeMutable<Glyph>(generateLocalSDF(fontStack, glyphID))); | |
} |
@@ -253,6 +253,57 @@ TEST(GlyphManager, LoadLocalCJKGlyph) { | |||
}); | |||
} | |||
|
|||
TEST(GlyphManager, LoadLocalCJKGlyphAfterLoadingRangeFromURL) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pozdnyakov I've added a unit test that reproduces the issue. The fixture is pretty large - but I haven't got an idea of how to create a more synthetic fixture for this test.
It requests 々(0x3005), which is in the range 12244-12543. This range overlaps with Katakana letters which are expected to be locally generated. Without the changes in GlyphManager
, this test will use the glyph fetched for the pbf for the katakana letter - and fails.
Ive as yet been unable to reproduce this issue on the macosapp, mbgl-glfw and on Android. The streets-v11 style doesn't show the behavior shown in #15405, so the fix here is speculative, though the unit test does show there is an underlying issue that is worth fixing. |
CI Failures:
|
Changelog:
|
Thanks @asheemmamoowala! I have a preference for the following changelog, any objections?
Reasons:
|
@chloekraw The platform teams will need to change the final message to reflect the platform version of GL-Native doesn't use |
@asheemmamoowala yeah, we always take that step to translate property names to the proper ones on each platform when doing every release. It doesn’t stop us from referencing specific properties in our changelogs. Also, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@asheemmamoowala thanks for the explanation and the unit test!
@pozdnyakov testTileSetFromTileURLTemplates failure is unrelated to this PR, should we add changelog and land it? |
3103104
to
5347783
Compare
Fixes #15405
TODO
cc @chloekraw @tmpsantos