Lag spikes when changing mods

[Layendan]

Type

Performance

Bug description

If user changes difficulty of a mapset in multiplayer freestyle, then decides to select extra mods, the game starts to lag a lot when selecting and unselecting mods.

1/3 tests: lag happened if user did not change difficulty
3/3 tests: lag happened after user changed difficulty
1/1 tests: lag happened without freestyle enabled

Idk if it's an issue introduced in #31850, or if it's from something else but can't recreate on release version.

Screenshots or videos

2025-02-14_19-05-22.mp4

Version

4c851a3

Logs

compressed-logs.zip

[smoogipoo]

I can't repro. Or well, I can, but it behaves the same as on the release build.

It looks like most of the time spent is inside the mod overlay itself, and as such is reproducible in song select:

Two things to note:

1. You are running the game in debug configuration, as evidenced by your logs. This will always perform worse than release builds.
2. What may be exacerbating problems is that selecting mods for the first time on a beatmap triggers difficulty calculation. If you're just coming out of song selection (as in the video), there may also be a short amount of time where the difficulty of more beatmaps is calculated than is actually required. This is because the difficulty icons in song select panels and the displayed difficulty in the mod selection both represent true star difficulty.

ALL OF THAT BEING SAID........

I have noticed several areas of concern. One of them is that mods aren't being correctly applied on room changes, due to the refactors performed here and which I specifically called out as unsure. Check out the star rating in this video:

2025-02-17.14-34-42.mp4

I hope this illustrates why I prefer to take on all multiplayer tasks myself - it is balancing on a knife's edge and not in a state where it can support multiple cooks in the kitchen. I am not looking into fixing this issue directly for now because I'm in the process of rewriting the screen, much like #31882 does for playlists.

For now, gameplay is saved due to one final call to updateSpecifics() when the screen suspends:

osu/osu.Game/Screens/OnlinePlay/Match/RoomSubScreen.cs

Lines 338 to 341 in 20d89f3

	public override void OnSuspending(ScreenTransitionEvent e)
	{
	// Should be a noop in most cases, but let's ensure beyond doubt that the beatmap is in a correct state.
	updateSpecifics();

[peppy]

I hope this illustrates why I #31260 (comment) - it is balancing on a knife's edge and not in a state where it can support multiple cooks in the kitchen. I am not looking into fixing this issue directly for now because I'm in the process of rewriting the screen, much like #31882 does for playlists.

Do you think this is worth (someone) tackling before release, or is it best to just leave it and wait for the refactor which will presumably also resolve this?

[smoogipoo]

I would fix it by reverting the change to onRoomUpdated(), though given that the Scheduler.AddOnce() was removed on the base method I'm not sure how "simple" that change is to make without causing adverse effects. Performance being one of them/the main one.

I'll look into it for a little bit but to be honest I would prefer to wait for the refactor just because it's all a little bit much right now.

[peppy]

Just leave it IMO, add to checklist for the rewrite. As long as it didn't break the solo flow it's a minor concern.