perf: Use TextElements within the TextComponent

[st-pasha]

Description

TextElement is a class that caches the layout of a particular string of text. When drawing any text on the screen, it is important to convert it to text-elements and then cache those, especially if there are many text fragments being displayed simultaneously.

This PR changes the TextComponent class so that it computes and stores a TextElement instead of using TextRenderer.render() directly. This improves the performance of a game, as it avoids costly recalculations of the text layout on every game tick.

Checklist

• The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
• I have read the Contributor Guide and followed the process outlined for submitting PRs.
• [-] I have updated/added tests for ALL new/updated/fixed functionality.
• [-] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
• [-] I have updated/added relevant examples in examples.

Breaking Change

• [-] Yes, this is a breaking change.
• No, this is not a breaking change.

Related Issues

Closes #1801

[erickzanardo]

Can't we put this logic inside FormatterTextRenderer somehow?

It doens't seems right to put logic of a specific renderer on the TextComponent

[st-pasha]

We have 3 TextRenderer implementations right now, and I had an idea for a fourth, but all of them are FormatterTextRenderers. Ideally, we would merge FormatterTextRenderer API into the TextRenderer, but that would be a breaking change for anyone who implements their own TextRenderer.

I would argue in favor of merging those two classes anyways, if the team agrees. But that ought to be in a separate PR, at which point we can simply remove the "else" part of this if-statement.

[spydon]

I vote for merging them too, I don't think there are many (if anyone at all) that has made their own TextRenderer implementation.

[wolfenrain]

  String _text;
  String get text => _text;

Normally we have the private at the top and the getter/setter below it right?

[spydon]

Doesn't that style become weird when adding dartdocs to the getter though? 🤔

[st-pasha]

As far as I can see, there is no Dart or Flutter official recommendations about this. The style that I'm currently using is taken from the example here: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#perform-dirty-checks-in-setters.

In practice, Flutter repo uses several styles: either

  /// The parent of this node in the tree.
  AbstractNode? get parent => _parent;
  AbstractNode? _parent;

  /// The current value stored in this notifier.
  ///
  /// When the value is replaced with something that is not equal to the old
  /// value as evaluated by the equality operator ==, this class notifies its
  /// listeners.
  @override
  T get value => _value;
  T _value;
  set value(T newValue) {
    if (_value == newValue)
      return;
    _value = newValue;
    notifyListeners();
  }

or

  /// Current code point.
  ///
  /// If the iterator has hit either end, the [_currentCodePoint] is -1
  /// and `_position == _nextPosition`.
  int _currentCodePoint = -1;

  ...

  /// The rune (integer Unicode code point) starting at the current position in
  /// the string.
  ///
  /// The value is -1 if there is no current code point.
  int get current => _currentCodePoint;

I guess we just need to decide which style we like more, and put this into our own style guide.

[spydon]

I like the first one, since we usually don't add dartdocs to both the public facing getter and the underlying value.