Why is this a thing at all? How has it survived this long? I don't know.
As far as I can tell this only manifests on selected beatmaps with "slow
swells" that spend the entire beatmap moving in the background. On other
beatmaps the tick is faded out, probably due to the initial transform
application that normally "works" but fails hard on these slow swells.
Can be seen on https://osu.ppy.sh/beatmapsets/1432454#taiko/2948222.
Closes https://github.com/ppy/osu/issues/28791.
The reason why nudging was not changing hyperdash state in catch was
that `EditorBeatmap.Update()` was not being called on the objects that
were being modified, therefore postprocessing was not performed,
therefore hyperdash state was not being recomputed.
Looking at the usage sites of `EditorBeatmap.PerformOnSelection()`,
about two-thirds of callers called `Update()` themselves on the objects
they mutated, and the rest didn't. I'd say that's the failure of the
abstraction and it should be `PerformOnSelection()`'s responsibility to
call `Update()` there. Yes in some of the cases here this will cause
extraneous calls that weren't done before, but the method is already
heavily disclaimed as 'expensive', so I'd say usability should come
first.
* Calculate hit windows in performance calculator instead of databased difficulty attributes
* Apply mods to beatmap difficulty in osu! performance calculator
* Remove `GreatHitWindow` difficulty attribute for osu!mania
* Remove use of approach rate and overall difficulty attributes for osu!
* Remove use of hit window difficulty attributes in osu!taiko
* Remove use of approach rate attribute in osu!catch
* Remove unused attribute IDs
* Code quality
* Fix `computeDeviationUpperBound` being called before `greatHitWindow` is set
This commit removes ISkinnableSwell for taiko swell animations. In place
of it, an event named UpdateHitProgress is added to DrawableSwell, and
the skin swells are converted to listen to said event and
ApplyCustomUpdateState, like how spinner skinning is implemented for
std.
