Underpinnings for Caching Text Layouts #51065
Closed
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.
Summary:
This adds infrastructure to let us start storing cached Android text layouts as part of a
ParagraphShadowNode. After this, we will clear them out, and propagate them to state. Right now, the flag doesn't do much, apart from extra work.This is done by adding
TextLayoutManagerExtended::supportsPreparedLayout(), andTextLayoutManager::PreparedLayouttypes, to shim between platforms, then on Android, we add aPreparedLayout, which is for now just an Android layout, with extra field (maxNumberOfLines, for some reason not exposed on recent versions).Android
TextLayoutManagerjava side is split a little bit, so that we reuse all the existing logic for prepared layouts. I tried to set up the boundary, so that we don't reserialize a MapBuffer after preparation, and for simplicity, this means source of truth for attachment count, and attachment sizes, now lives on the layout. This means we need to change boundary a bit, where we are no longer able to pass in a buffer to fill from C++ side of attachment positions.Changelog: [Internal]
Differential Revision: D73970149