Record why the chat splitter timer stays off the renderer thread

This commit is contained in:
Thorsten Sommer 2026-09-16 13:20:15 +02:00
parent 0993517608
commit 9535b26f4d
Signed by untrusted user who does not match committer: tsommer
GPG Key ID: 371BBA77A02C0108

View File

@ -39,6 +39,16 @@ public partial class Chat : MSGComponentBase
this.splitterPosition = this.SettingsManager.ConfigurationData.Workspace.SplitterPosition;
this.splitterSaveTimer.AutoReset = false;
//
// Mind that this handler deliberately stays off the renderer thread, although it writes the
// configuration data from a thread pool thread. The position is a single double, and every
// target we ship is 64 bit, so the write cannot tear -- and the worst a lost one could do is
// a splitter standing somewhere else after the next start. What a jump to the dispatcher
// would cost instead is paid by the user: storing the settings serializes all of them and
// writes two files, and it would do that in the very queue which draws the drag they are in
// the middle of. The splitter then stutters under their hand. Whoever synchronizes the
// configuration data one day should do it without moving that work onto the renderer.
//
this.splitterSaveTimer.Elapsed += (_, _) =>
{
this.SettingsManager.ConfigurationData.Workspace.SplitterPosition = this.splitterPosition;