Text rendering is laggy with long strings

[outfoxxed]

Type

Performance

Bug description

Long text lines in beatmap comments seem to cause far more lag than they should.

How to reproduce:

1. Play the game a bit. It seems to lower framerates far less if you go directly to the comments after opening the game.
2. Open a map with a lot of long comments visible at once
   a. https://osu.ppy.sh/beatmapsets/1749893#osu/3579919 has a copypasta repeated at the top which works.
3. Scroll in the comments and watch the framerate.

Renderer is Automatic (OpenGL).

Screenshots or videos

output.mp4

Version

2024.906.2-lazer

Logs

Zip seemed to contain logs from every prior osu launch. Pulled out logs for the latest.

1727735543.auth.log
1727735543.input.log
1727735543.network.log
1727735543.performance.log
1727735543.runtime.log

[peppy]

At a casual glance this looks related to not caching character positions / line breaks when rendering text

Best to leave out your own likely-wrong hypothesis when reporting an issue 😅. Chance of being wrong is near 100%.

[outfoxxed]

Apologies, removed.

[bdach]

I profiled this a bit today but I don't see an angle to continue down here. Firstly it's not as bad here as on the video, and secondly it's just that it's a bit of everything at once:

Masking, screen space calcs, the whole 9 yards. The sheer number of text sprites moving off and on screen is probably gonna make this happen, but how to address that? Unloading comments?

[peppy]

BufferedContainer with caching turned on may be a solution.

[bdach]

Last time I wanted to spam buffered containers to fix an issue was with beatmap cards which got rejected on grounds that it will eat vram for breakfast. In this context maybe it's not as egregious because comments don't change size that often, but it is still a potentially-infinite list of comments, so I wouldn't see buffered container usage without comment unload anyway.

[peppy]

Would have to include use of DelayedAsyncLoadUnload probably maybe.

[smoogipoo]

The first question should be "why is it so bad", not "let's add more components on top of it to hide the issue". This is not some gigantic wall of text that it's rendering - it's very well batchable.

First: can you actually replicate this every time? I.e. after restarting osu!?

I managed to repro it once, and saw this in global statistics:

Which indicates something horribly wrong is going on with batching. And from the looks of that screenshot -- I didn't manage to capture the FlushBatchSource section because I wasn't interested in it at the time -- it appears to indicate that it's the result of text glyphs being spread across multiple texture atlases.

The above optimisation would come under ppy/osu-framework#5986 + ppy/osu-framework#3345 + ppy/osu-framework#5508 + ppy/osu-framework#5765 and any other PRs/issues linked to from those, as well as several other techniques that can be used to optimise further without increasing atlas size (multi-texture bindings).

[peppy]

@smoogipoo the report was only when scrolling, so I don't think it's draw call / batching related / atlas related.

[smoogipoo]

I can 110% guarantee you it is.

[peppy]

I don't understand but this is not high priority so I'll drop it.

[smoogipoo]

To be clear, if you want to reproduce what I'm seeing:

• If you start up the game and immediately go into beatmap listing, type 3579919, and scroll to the text it may be fine. It's not guaranteed but it reduces the chance that glyphs end up on different atlases.
• If you start up the game, go into song select, open beatmap listing, type 3579919, and scroll to the text it may break. Again not guaranteed because this depends on how the atlases end up, but in theory any additional pressure on the atlas can cause it to spill just right (in the wrong kind of way).