-
-
Notifications
You must be signed in to change notification settings - Fork 915
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
refactor!: Simplify text rendering pipeline (#2663)
While studying the existing text rendering pipeline and infrastructure, in order to better document it and add some easier user-facing ways to render rich text, I found it to be on a slightly overcomplicated state that seems to me to be an artifact of a migration. Let me first briefly describe how it works with some diagrams (I am writing docs for everything and will re-use this content but wanted to propose this PR first as it will change how things look like). We have 3 hierarchies related to rendering: renderers: children of TextRenderer, these define how to render text (style). do not include text formatters: children of TextFormatter, this also define how to render text (style), but a bit more higher level than TextRenderer. elements: these are laid-out, styled and ready-render pieces of text (style + string), created by formatters Note that the renderers and formatters kinda serve the same purpose, but the renderers are a more low-level API. Here is how it it looks like today: Not only that but all of our TextRenderer are actually FormatterTextRenderer, which just use a formatter to "comply" with the "renderer" interface. There are no "raw" TextRenderers anymore. This current structure seems to clearly derive from an unfinished transition into the new, higher level and more flexible "formatter" structure while still supporting the "renderers" while we transition. That transition, though, seems to have completed. The current state makes things more complicated as our current versions of components (TextComponent and TextBoxComponent), specifically the former, have branching code to support both the raw TextRenderer and the specific FormatterTextRenderer implementation, which breaks the inheritance encapsulation and voids its purpose in the first place. The purpose of this PR is to simplify this class structure by: remove the base TextRenderer rename FormatterTextRenderer to TextRenderer: all renderers are formatter-based now update all references simplify the code of the components by only dealing with (former FormatterTextRenderer) TextRenderers This is what it looks like now: Note that while this is a breaking change, it should not affect most users as they should be using much more user-facing classes, like the aforementioned components, instead of the backing implementations. In fact even if they use the renderers, they probably use one of the concrete implementations anyway, TextPaint or SpriteFontRenderer. Notwithstanding, I added migration instructions below. This is a small step towards a world where we completely combine the converts of renderers and formatters, as, in my eyes, they do the same thing (carry the style information w/o the text). Possible future (but definitely breaking) changes: remove renderers entirely and use formatters directly consider renaming formatters to renderers (or not) rename TextPaint as the name does not make sense in any hierarchical model we use (what I am really interested in): allow the creation of text_ and text_box_ components directly from renderers + elements
- Loading branch information
1 parent
d172146
commit 34f69b9
Showing
10 changed files
with
102 additions
and
115 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file was deleted.
Oops, something went wrong.
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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