[Net11] Keep SplitContainer content alive while the splitter moves

[KlausLoeffelmann]

User story

As a WinForms user, I want both SplitContainer panels to repaint continuously while I move the splitter in VisualStylesMode.Net11 and later modes, so that the UI remains visually coherent, responsive, and usable throughout the interaction.

Rationale and motivation

Moving a splitter is direct manipulation: users expect the content on both sides to track the pointer or keyboard interaction continuously. The current approach is still basically the approach from pre-Win98, where not the content of an UI-Object moved, but the symbolic-indicated outline. SplitContainer could currently leave Panel1 and Panel2 content stale, incomplete, or even with splitter-drawing artifacts, while the splitter moves.

This is more than a cosmetic defect. When the control does not paint reliably during the interaction, the user loses the visual relationship between the splitter position and the resulting layout. The act of moving the splitter can become an accessibility problem in its own right, especially for users who depend on strong visual feedback, magnification, reduced pointer precision, keyboard operation, remote sessions, or slower hardware.

User benefits

• Immediate and continuous visual feedback while dragging or keyboard-moving the splitter.
• More predictable direct manipulation and reduced visual confusion.
• Better usability for users with accessibility needs.
• Consistent behavior across light and dark rendering and across local and remote sessions.
• Confidence that realistic, deeply nested panel content remains stable without leaks or unacceptable performance regressions.

Scope

• Apply the continuous repaint behavior when VisualStylesMode is Net11 or a later mode.
• Repaint the relevant content of both Panel1 and Panel2 throughout splitter movement, not only after the interaction completes.
• Preserve intended behavior in Classic mode.
• Cover mouse and keyboard splitter movement where applicable.
• Avoid flicker, re-entrant layout/paint loops, excessive invalidation, handle churn, memory leaks, and material performance regressions.

Acceptance criteria

• During splitter movement in VisualStylesMode.Net11 and later, visible content in both panels updates continuously and reliably.
• The final layout and rendering are correct after the interaction ends.
• Mouse and keyboard interaction paths are covered where the control supports them.
• Classic mode behavior remains correct and does not regress.
• Light and Dark Mode behavior is verified.
• Behavior is verified in a Terminal Services / Remote Desktop session.
• Realistic lightweight, medium, and heavy panel payloads are exercised.
• Heavy exploratory coverage includes at least three nested levels of TableLayoutPanel.
• Windows on ARM hardware and a genuinely slow device such as a Surface Go 2 are exercised. Klaus owns both types of machines and can be asked to test at any time.
• Automated tests demonstrate the regression before the fix where practical and pass after the fix.
• Relevant tests pass locally and in CI.
• Benchmark or stress results provide actual before/after numbers for repaint/resize behavior and memory stability.
• No sustained managed or native memory growth, GDI/User handle leak, or control-handle churn is observed under repeated heavy splitter movement.

Definition of Done

• The rendering and layout root cause is understood and the chosen approach is documented.
• The implementation is appropriately scoped to VisualStylesMode.Net11 and later, with no unintended Classic-mode behavior change.
• Code follows existing WinForms invalidation, layout, buffering, and painting conventions.
• Unit tests cover relevant splitter movement, invalidation/repaint behavior, orientation, handle state, and mode-specific behavior.
• Tests run successfully locally and in the CI build.
• A sample application supports lightweight, medium, and heavy payload configurations and documents its exploratory test matrix.
• Exploratory testing covers light mode, Dark Mode, Classic mode, Terminal Services / Remote Desktop, Windows on ARM, and slow hardware.
• Benchmark/stress methodology, environment, duration, and before/after results are recorded and reproducible.
• Memory, GDI/User handles, CPU cost, responsiveness, flicker, and final rendering correctness have been assessed.
• Accessibility impact is considered explicitly, including keyboard movement and visual feedback during direct manipulation.
• Public behavior changes and any compatibility considerations are documented.
• The implementation and evidence are reviewed.
• Any required release note or servicing/release documentation is completed.

Scheduling note

This is a close call for RC2, but schedule pressure must not be used to waive any important acceptance criterion or Definition of Done item. If the complete, validated change cannot be delivered for 11.0-rc2 for whatever reason (longer hours are NOT an option!), move the work to .vNext-Preview1 rather than reducing scope, testing, accessibility validation, personal well-being, or performance and leak analysis.