Fix daily challenge marker text spacing

[bdach]

Closes #32908.

Have you ever been in a situation wherein you find out you fixed a bug that you didn't know existed, but that makes another bug appear because it was relying on the other bug? This is where I'm at right now.

But, to start from the top.

TextFlowContainer.Text (the setter) is a convenience property that you use to set the text in one go. Internally it uses AddText().

AddText()'s xmldoc says:

The \n character will create a new paragraph, not just a line break.
If you need \n to be a line break, use <see cref="AddParagraph{TSpriteText}(LocalisableString, Action{TSpriteText})"/> instead.

That's right. This portion of xmldoc was straight up false and silently broken before ppy/osu-framework#6556. If you want to check that out yourself, apply the following patch to framework:

diff --git a/osu.Framework.Tests/Visual/Containers/TestSceneTextFlowContainer.cs b/osu.Framework.Tests/Visual/Containers/TestSceneTextFlowContainer.cs
index 464f47c2c..e1ad521a7 100644
--- a/osu.Framework.Tests/Visual/Containers/TestSceneTextFlowContainer.cs
+++ b/osu.Framework.Tests/Visual/Containers/TestSceneTextFlowContainer.cs
@@ -180,6 +180,22 @@ public void TestAlignmentIsCorrectWhenLineBreaksAtLastWordOfParagraph(Anchor tex
             });
         }
 
+        [Test]
+        public void TestSetTextWithNewLine()
+        {
+            AddStep("set text", () => textContainer.Text = "this text\nhas a newline");
+            AddStep("clear and add text", () =>
+            {
+                textContainer.Clear();
+                textContainer.AddText("this text\nhas a newline");
+            });
+            AddStep("clear and add paragraph", () =>
+            {
+                textContainer.Clear();
+                textContainer.AddParagraph("this text\nhas a newline");
+            });
+        }
+
         private void assertSpriteTextCount(int count)
             => AddAssert($"text flow has {count} sprite texts", () => textContainer.ChildrenOfType<SpriteText>().Count() == count);
 

On master, there will be a difference between the first two steps, and the third. On 2025.321.0, there will be none.

My working theory as to why this was always busted is that the corresponding code that was there before just straight up ran too late. The height of the container is being changed after the flow has laid itself out, without adjusting subsequent children in any way.

There is potentially a discussion to be had as to whether the emergent behaviour of TextFlowContainer.Text with respect to \n character is correct, but I'm just going to start with this diff and see what the reaction is.

[peppy]

I don't get the xmldoc so maybe this says the underlying behaviour should change. Why would \n ever become a paragraph? Is there a reason we want this?

Might as well fix the fps counter in this PR while we're here.

[bdach]

Why would \n ever become a paragraph? Is there a reason we want this?

Beats me. All of that behaviour predates me. Blame points to ppy/osu-framework#791.

I'm fine with changing behaviour but the question would be to what. Should newlines just break a line without considering paragraphs? In what circumstances? Should two newlines indicate a new paragraph? Heck knows.

[peppy]

I'd expect newline to always be a newline. Especially in the case of AddText? To add a new paragraph, I'd expect to use AddParagraph.

Trying to rationalise the implemented behaviour, maybe it was trying to do best-effort paragraph translation for .Text=proseContent?

---

to be clear, i'd prefer these issues are fixed with osu-side code changes first, we can figure framework changes later if we can agree on something.

[bdach]

Might as well fix the fps counter in this PR while we're here.

Attempted fix in 3f98dd9. It's a bit different because of how the fps display is written (does four .AddParagraph() calls in Update() so I don't really want to touch it too much)