refactor!: Kill TextRenderer, Long Live TextRenderer #2683
Merged
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.
Description
This will:
TextRenderer
inheritance chainTextRenderer
in the baseTextFormatter
TextFormatter
toTextRenderer
and appropriate referencesThat is because both essentially do the same job; encompass the style (or "how") information about how to render text, but using two slightly different interfaces. While that could allow for more flexibility, it is a faux choice that needlessly complicates the pipeline. By having a single interface to comply with, we still allow for custom renders while at the same time making all the code downstream simpler to use and understand.
In fact the main goal is to vastly simplify the rendering pipeline, while at the same time providing the minimum amount of breaking changes. In fact this should just work "as is" for the majority of use cases as long as you are importing the
package:flame/text.dart
module instead of individual source classes.That is because people should probably be using the concrete classes
TextPaint
andSpriteFontRenderer
, if at all (or the provided components under FCS). These are kept with the same name and have the same methods, even though the underlying inheritance chain has completely changed.If you have custom renderers or formatters at all, your life has actually become much simpler, and migrating should be trivial and allow you to delete some connectors/helper code.
A full description of what the text rendering pipeline looks like after this PR can be seen on the updated docs (doc/flame/rendering/text_rendering.md).
Prior art
The first PR has a better breakdown of the ideals explained here, alongside an exploration of the current state of affairs before this series of smaller PRs:
Diagram Diff
Before:
After:
Checklist
docs
and added dartdoc comments with///
.examples
ordocs
.Breaking Change?
Migration instructions
This is definitely a breaking change, but probably should not affect most users. These are the steps to migrate:
package:flame/text.dart
)TextPaint
,SpriteFontRenderer
,TextComponent
orTextBoxComponent
, no change should be necessaryDebugTextFormatter
, it is now calledDebugTextRenderer
TextRenderer
instead (and maybe change its name from Formatter to Renderer). they will still be doing the same job