Results in a "MSVC_RUNTIME_LIBRARY value 'MultiThreadedDLL' not known for this ASM compiler" otherwise, and zstd doesn't support the relevant ASM code for MSVC anyway.
Previously, PerformanceTracker registered a callback to be updated on
emulation state changes. PerformanceTrackers live in a global variable
(g_perf_metrics) within libvideocommon. The callback was stored in a
global variable in libcore. This created a race condition at shutdown
between these libraries, when the PerfTracker's destructor tried to
unregister the callback.
Notify the PerfTracker directly from libcore, without callbacks, since
Core.cpp already references g_perf_metrics explicitly. Also rename
Core::CallOnStateChangedCallbacks to NotifyStateChanged to better
reflect what it's doing.
a1691a4 made it so analytics start events can only be generated when
starting the main activity. However, some users launch Dolphin's
emulation activity from a separate frontend application, bypassing
Dolphin's main activity. This change adjusts the logic so that start
events can be generated if any activity is started after 6 hours of
inactivity. This more closely matches the behavior we had before
a1691a4, while still ensuring duplicate start events aren't generated.
I've also fixed the inconsistent indentation in ActivityTracker.kt.
Require callers of Config::AddConfigChangedCallback and
CPUThreadConfigCallback::AddConfigChangedCallback to handle the returned
ConfigChangedCallbackIDs to hopefully prevent future issues with
callbacks getting called after their associated objects have been
destroyed.
Use a single lambda as a callback which calls InitCustomPaths and
RefreshConfig instead of having separate callbacks for each of them.
This fixes the callback for InitCustomPaths not being removed on
shutdown; the callback for the lambda (previously for RefreshConfig) is
already removed in Shutdown().
Prevent SetHardcoreMode from being called after m_client is set to
nullptr. rc_client_set_hardcore_enabled() checks for nullptr so this
didn't cause any problems, but better not to rely on that.
Also prevents multiple SetHardcoreMode callbacks from piling up when
repeatedly toggling Config::RA_ENABLED.
Remove ConfigChangedCallback in MainWindow's destructor to prevent the
callback from accessing the destroyed MainWindow afterward.
After MainWindow is destroyed UICommon::Shutdown calls
LogManager::Shutdown which ultimately triggers any remaining callbacks.
This resulted in calling MainWindow::OnHardcoreChanged, which crashed in
debug builds and didn't have any obvious effect in release builds.
