From 9535b26f4df681ce742d6d52d044d8f5c9782a07 Mon Sep 17 00:00:00 2001 From: Thorsten Sommer Date: Wed, 16 Sep 2026 13:20:15 +0200 Subject: [PATCH] Record why the chat splitter timer stays off the renderer thread --- app/MindWork AI Studio/Pages/Chat.razor.cs | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/app/MindWork AI Studio/Pages/Chat.razor.cs b/app/MindWork AI Studio/Pages/Chat.razor.cs index 0ab09d15..7c88c863 100644 --- a/app/MindWork AI Studio/Pages/Chat.razor.cs +++ b/app/MindWork AI Studio/Pages/Chat.razor.cs @@ -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;