mirror of
https://github.com/ppy/osu.git
synced 2024-10-01 09:47:29 +08:00
c64a919a9d
As pointed out in https://github.com/ppy/osu/discussions/16435, beatmaps with too many control points (usually added via external automation apps) could cause the lazer editor to grind to a halt. The overheads here are mostly from the GL side. An eventual goal would be to render this in a smarter way, rather than using thousands of drawables. Until that, this optimisation should help reduce the overhead by omitting control points in close proximity that are redundant for display purposes. I've tried to contain this in the display logic directly, with the goal that it can be ripped out as fast as it was added. Certainly required more changes than I hoped for, but I don't think it's too ugly.
73 lines
3.4 KiB
C#
73 lines
3.4 KiB
C#
// Copyright (c) ppy Pty Ltd <contact@ppy.sh>. Licensed under the MIT Licence.
|
|
// See the LICENCE file in the repository root for full licence text.
|
|
|
|
using System.Collections.Specialized;
|
|
using System.Linq;
|
|
using osu.Framework.Bindables;
|
|
using osu.Game.Beatmaps.ControlPoints;
|
|
|
|
namespace osu.Game.Screens.Edit.Components.Timelines.Summary.Parts
|
|
{
|
|
/// <summary>
|
|
/// The part of the timeline that displays the control points.
|
|
/// </summary>
|
|
public class ControlPointPart : TimelinePart<GroupVisualisation>
|
|
{
|
|
private readonly IBindableList<ControlPointGroup> controlPointGroups = new BindableList<ControlPointGroup>();
|
|
|
|
protected override void LoadBeatmap(EditorBeatmap beatmap)
|
|
{
|
|
base.LoadBeatmap(beatmap);
|
|
|
|
controlPointGroups.UnbindAll();
|
|
controlPointGroups.BindTo(beatmap.ControlPointInfo.Groups);
|
|
controlPointGroups.BindCollectionChanged((sender, args) =>
|
|
{
|
|
switch (args.Action)
|
|
{
|
|
case NotifyCollectionChangedAction.Reset:
|
|
Clear();
|
|
break;
|
|
|
|
case NotifyCollectionChangedAction.Add:
|
|
foreach (var group in args.NewItems.OfType<ControlPointGroup>())
|
|
{
|
|
// as an optimisation, don't add a visualisation if there are already groups with the same types in close proximity.
|
|
// for newly added control points (ie. lazer editor first where group is added empty) we always skip for simplicity.
|
|
// that is fine, because cases where this is causing a performance issue are mostly where external tools were used to create an insane number of points.
|
|
// if (Children.Any(g => Math.Abs(g.Group.Time - group.Time) < 1000 && g.IsRedundant(group)))
|
|
// continue;
|
|
|
|
Add(new GroupVisualisation(group));
|
|
}
|
|
|
|
break;
|
|
|
|
case NotifyCollectionChangedAction.Remove:
|
|
foreach (var group in args.OldItems.OfType<ControlPointGroup>())
|
|
{
|
|
var matching = Children.SingleOrDefault(gv => gv.Group == group);
|
|
|
|
if (matching != null)
|
|
matching.Expire();
|
|
else
|
|
{
|
|
// due to the add optimisation above, if a point is deleted which wasn't being displayed we need to recreate all points
|
|
// to guarantee an accurate representation.
|
|
//
|
|
// note that the case where control point (type) is added or removed from a non-displayed group is not handled correctly.
|
|
// this is an edge case which shouldn't affect the user too badly. we may flatted control point groups in the future
|
|
// which would allow this to be handled better.
|
|
Clear();
|
|
foreach (var g in controlPointGroups)
|
|
Add(new GroupVisualisation(g));
|
|
}
|
|
}
|
|
|
|
break;
|
|
}
|
|
}, true);
|
|
}
|
|
}
|
|
}
|