Summary of the Pull Request

Reduce Home-page XAML materialization/layout work with a purpose-built module-row template, while retaining the existing SettingsCard control, commands, toggles, automation peer and virtualization. Quick Access keeps its original template.

In a matched x64 Release comparison, warm Home navigation-to-first-render median improved from 241.40 ms to 174.90 ms (27.5%). This is a scoped Home rendering improvement, not an overall Settings startup claim.

Related: #34026. Independent of the startup/activation work in #49891; this does not close the broader startup issue.

PR Checklist

• [x] Communication: Requested as an independently reviewable draft during the Settings audit.


• [ ] Tests: Home-row regression checklist updated; isolated rendering/behavior comparisons completed, but physical input, live high contrast and mixed-DPI scenarios remain pending.

Closes, localization, developer/API documentation, new binaries and external documentation updates: N/A. No new strings, dependencies or binaries.

Detailed Description of the Pull Request / Additional comments

• 
  src\settings-ui\Settings.UI.Controls\ModuleList\ModuleList.xaml and ModuleList.xaml.cs: add optional ItemContainerStyle. Apply it during ItemsRepeater.ElementPrepared, before first measure, rather than building the default template and replacing it afterward. Changing the style updates existing realized cards; clearing it restores implicit/default styling without realizing additional items.


• 
  src\settings-ui\Settings.UI\SettingsXAML\Views\DashboardPage.xaml: opt Home into a scoped SettingsCard template. Remove the unused description subtree and general-purpose content/wrapping/spacing triggers, and replace instantaneous storyboard/keyframe objects with visual-state setters. Preserve row geometry, light/dark/high-contrast brush mappings, interactive states and the underlying SettingsCard/ButtonBase implementation.


• 
  src\settings-ui\Settings.UITests\SettingsTests.md: add Home-row regression scenarios, including sorting, locked modules, row/toggle behavior, focus, themes, scaling and Quick Access isolation.

The template is derived from CommunityToolkit SettingsControls 8.2.251219 (source revision a6b4dc451c0e54dd29f58743894a956100e7f713). Toolkit-private resource keys are not available from the page, so the Home-scoped aliases use their corresponding public brushes.

Risk: medium. A specialized template must be kept aligned with future toolkit styling/input/accessibility changes. Scope is intentionally Home-only; no settings schemas, IPC, persistence, module activation or viewmodel lifecycle changes. Temporary measurement/fixture hooks are not included in the production diff.

Validation Steps Performed

Matched rendering comparison

| Metric | Original template | Home template | Reduction |
| --- | ---: | ---: | ---: |
| Warm first-render median | 241.40 ms | 174.90 ms | 27.5% |
| Warm first-render p95 | 265.87 ms | 189.37 ms | 28.8% |
| Median UI-thread CPU through first render | 234.38 ms | 156.25 ms | 33.3% |
| Realized module rows | 27 / 33 | 27 / 33 | Unchanged |
| Normal row visual nodes | 33 | 31 | 2 fewer |
| Home visual nodes | 1,410 | 1,356 | 54 fewer |

Protocol: same optimized x64 Release diagnostic binary, with the optional style cleared before row population for baseline and enabled for candidate; four fresh processes in baseline/candidate/candidate/baseline order; 20 warm Home visits per process, 40 samples per variant, excluding first visits. Navigate to a minimal neutral page between visits. Fixed 1280 x 800 client pixels, XAML scale 1.0, light/LTR, identical synthetic settings and window placement. No UIA or visual-tree enumeration during timed samples. Baseline process medians were 242.06/241.01 ms; candidate medians were 174.12/177.97 ms.

Measurement source was bb656da414e09808f6d25c98dca4313e7e37f828; the branch was subsequently fast-forwarded over the unrelated PowerAccent change to 71340eed47f7cf6f53b68b86a7939ad1240c3de7 before publication. Timings end at the first CompositionTarget.Rendering callback after loading: pre-present, not DWM presentation or physical input-to-screen latency. Results apply to this workload/viewport, not every Settings page.

Rendering and behavior parity

Content-validated in-process RenderTargetBitmap captures matched raw RGBA bytes exactly for all ten baseline/candidate pairs: light/dark Normal, PointerOver, Pressed and Disabled, plus light/dark RTL. Both the full captured XAML subtree and module-list region match. Initial valid Normal-light whole-window captures also matched. Blank broader HWND captures were rejected and replaced, not counted as evidence. XAML captures exclude the DWM backdrop and native captions.

Isolated baseline/candidate behavior checks each produced 12 passed, 0 failed, 3 unsupported. Covered one model change per toggle with no row-command dispatch, distinct row/toggle focus stops, lock disabling only the toggle, programmatic status refresh suppressing user callbacks, stock-equivalent automation names, updating the same realized card on style change, and restoring the stock template on clear.

The detached RDP input desktop prevented physical click/keyboard validation. The stock peer also did not expose the expected WinRT Invoke-provider interface in this setup, so row-click dispatch is not claimed as a runtime pass. Live high contrast and mixed-DPI interaction remain manual checklist items; high-contrast resource correspondence was source-checked only.

Normal build and isolation

Ordinary Settings x64 Release and Settings.UI.Controls ARM64 builds succeeded after all temporary profiling helpers/hooks were removed. ARM64 was compilation, not ARM64 hardware runtime coverage. The comparisons used synthetic settings with Runner actions suppressed and did not replace/stop the existing Settings or Runner instances. No committed automated UI-test suite was added; the isolated diagnostic comparisons and remaining manual scenarios are described above.