LibGfx+Tests: Support refining strip-refined symbols with export control#26578
Merged
nico merged 1 commit intoSerenityOS:masterfrom Jan 27, 2026
Merged
LibGfx+Tests: Support refining strip-refined symbols with export control#26578nico merged 1 commit intoSerenityOS:masterfrom
nico merged 1 commit intoSerenityOS:masterfrom
Conversation
When we don't export some symbols, symbol indices are different in different symbol dictionary sections. For example, in the included test, segment 1 exports 7 symbols, and segment 2 refers to it, but only exports 3 of these 7 symbols, and it only exports 1 of the 4 symbols itself defines. So within segment 2, indices 0-10 are valid. But in segment 3, which refers to segment 2, only indices 0-3 are valid, and they refer to the symbols that have indices 0, 1, 6, and 10 in segment 2. This is mostly a problem for the writer (see SerenityOS#26510 / d15f574). When the text region refines its symbol 3, the code used to look up the symbol ids that it referred to. But those indices were in the namespace of segment 2, but we used the symbol list from segment 3. As a fix, don't store symbol dictionary results as a SymbolDictionarySegmentData::HeightClass::Symbol but just as a BilevelImage. For regular symbols and regular refined symbols, it doesn't make a difference. Strip-refined symbols are converted to bitmaps eagerly instead of only when they are refined, but in return this needs less code, it handles indices correctly, and chains of strip-refined symbols are no longer O(n^2) (...not that these happen in practice). The new test is the same as bitmap-symbol-symbolrefine-textrefine.json (or bitmap-symbol-symhuffrefine-textrefine.json), but the last symbol_region sets `export_flags_for_referred_to_symbols` to not export temporary symbols from its referred-to symbol dictionaries, and it sets `"exported"` to false for its internal symbols (and symbol_ids are adjusted to match).
github-actions
bot
added
the
👀 pr-needs-review
github-actions
bot
removed
the
👀 pr-needs-review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When we don't export some symbols, symbol indices are different in different symbol dictionary sections.
For example, in the included test, segment 1 exports 7 symbols, and segment 2 refers to it, but only exports 3 of these 7 symbols, and it only exports 1 of the 4 symbols itself defines. So within segment 2, indices 0-10 are valid. But in segment 3, which refers to segment 2, only indices 0-3 are valid, and they refer to the symbols that have indices 0, 1, 6, and 10 in segment 2.
This is mostly a problem for the writer (see #26510 / d15f574).
When the text region refines its symbol 3, the code used to look up the symbol ids that it referred to. But those indices were in the namespace of segment 2, but we used the symbol list from segment 3.
As a fix, don't store symbol dictionary results as a SymbolDictionarySegmentData::HeightClass::Symbol but just as a BilevelImage. For regular symbols and regular refined symbols, it doesn't make a difference. Strip-refined symbols are converted to bitmaps eagerly instead of only when they are refined, but in return this needs less code, it handles indices correctly, and chains of strip-refined symbols are no longer O(n^2) (...not that these happen in practice).
The new test is the same as bitmap-symbol-symbolrefine-textrefine.json (or bitmap-symbol-symhuffrefine-textrefine.json), but the last symbol_region sets
export_flags_for_referred_to_symbolsto not export temporary symbols from its referred-to symbol dictionaries, and it sets"exported"to false for its internal symbols (and symbol_ids are adjusted to match).