Based on feedback I've heard more than once ([most
recently](https://github.com/ppy/osu/discussions/36933)), there's too
much overlap compared to stable. And it can sound a bit "jumbled" as a
result, especially when transitioning between two songs with loud and
"complex" audio.
This also fixes noticeable audio glitching that some users may have been
experiencing when switching tracks.
---
Unless there's any very loud objections, I'd ask that review is on the
code not the audible change. This is the kind of change that I tweak to
my personal spec and then push out to hear the general reaction.
### b8d0dfe2ed Better default preview time
based on global fade
This is an oversight. The preview point wasn't being offset to account
for the fade in. This is something we do when generating web-side
previews, which allows for the actual preview point to be audible,
rather than mid-fade.
### 8de323b68c Adjust fade in and fade out
during track transitions to reduce overlap
Yes, I'm aware that the delay is not accounted for in the constant. This
is intentional because it sounds better. I want this to be an internal
adjustment which is not to be considered by any external usages of those
constants. Just sounds better.
### aab01b0fe5 Remove weird/dated schedule
usage
This causes audible artifacts in playback. The track is not set to zero
volume early enough. Original change was made in [this ancient
PR](https://github.com/ppy/osu/pull/9792) (see
[commit](https://github.com/ppy/osu/commit/688e4479506645bdacee7cdc7ae9ee9deaa5f1b4)).
The original failure does not occur. Tests still pass. I'd argue that if
we encounter this again, it's an issue at the call site, not this code.
This is a drive-by fix, as I noticed this glitching while working on the
main issue here. Arguably should be it's own PR 🤷 .
Unfortunately breaks a few classes (which is fixable), and also breaks
Moq/Castle dynamic proxies (which is unfortunate).
Relevant error:
System.TypeLoadException : Method 'GetPanelBackground' in type 'Castle.Proxies.IWorkingBeatmapProxy' from assembly 'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
Stack Trace:
at System.Reflection.Emit.TypeBuilder.CreateTypeNoLock()
at System.Reflection.Emit.TypeBuilder.CreateTypeInfo()
at Castle.DynamicProxy.Generators.Emitters.AbstractTypeEmitter.BuildType()
at Castle.DynamicProxy.Generators.BaseInterfaceProxyGenerator.GenerateType(String typeName, INamingScope namingScope)
at Castle.DynamicProxy.Generators.BaseProxyGenerator.<>c__DisplayClass13_0.<GetProxyType>b__0(CacheKey cacheKey)
at Castle.Core.Internal.SynchronizedDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
at Castle.DynamicProxy.Generators.BaseProxyGenerator.GetProxyType()
at Castle.DynamicProxy.DefaultProxyBuilder.CreateInterfaceProxyTypeWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyTypeWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, IInterceptor[] interceptors)
at Moq.CastleProxyFactory.CreateProxy(Type mockType, IInterceptor interceptor, Type[] interfaces, Object[] arguments) in C:\projects\moq4\src\Moq\Interception\CastleProxyFactory.cs:line 50
In theory it would be possible to fix this via application of
[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]
onto the `osu.Game` assembly, but I think this would be bad precedent.
This is an effort to improve general performance at song select. At
least on the metal renderer, I can notice very high draw frame overheads
related to texture uploads.
By reducing the size of the texture uploads to roughly match what is
actually being displayed on screen (using a relatively inexpensive crop
operation), we can bastly reduce stuttering both during initial load and
carousel scroll.
You might ask if it's safe to disable mipmapping, but I've tested with
lower resolutions and bilinear filtering seems to handle just fine.
Bilinear without mipmaps only falls apart when you scale below 50% and
we're not going too far past that at minimum game scale, if at all.
After the recent changes introducing cancellation support to
`WorkingBeatmap`, it turned out that if the cancellation support was
used, `GetPlayableBeatmap()` would raise timeout exceptions rather than
the expected `OperationCanceledException`.
To that end, split off a separate overload for the typical usage, that
catches `OperationCanceledException` and converts them to beatmap load
timeout exceptions, and use normal `OperationCanceledException`s in the
overload that requires a cancellation token to work.