klevze
603af17e56
The repo carried two parallel UIs (WPF + WinUI) sharing Models/Services via
cross-directory Link includes. Now that WinUI is the only frontend, collapse
the structure so the WinUI project IS the repo root instead of a nested
sibling folder:
- Delete the WPF project entirely (App.xaml, MainWindow.xaml, csproj) and its
bin/obj output
- Move AmiReel.WinUI/* up to the repo root (App, MainWindow, MainPage,
DialogHelper, Assets, Package.appxmanifest, app.manifest, Properties,
.github/instructions, AGENTS.md) via git mv, preserving history
- Rename AmiReel.WinUI.csproj -> AmiReel.csproj; regenerate the solution as
AmiReel.slnx (the newer XML solution format) with a single project
- Rename namespace AmigaDB.VideoRenderer.{Models,Services} -> AmiReel.{...}
and AmiReel_WinUI -> AmiReel across all files, including the embedded
ffmpeg/ffprobe resource logical names in the csproj and ToolExtractor
- Models/ and Services/ no longer need the Link-based cross-directory
<Compile Include>; they're picked up by the SDK's default globbing now
that they live under the project directory
- Rename assets/ -> branding/ (source icon art) to avoid a case-insensitive
collision with Assets/ (packaged tile art) once both sit at repo root
- Merge the two .gitignore files into one; track the PublishProfiles pubxml
files instead of ignoring them (no secrets, and they keep publish
reproducible across machines) as branding, gitignore, etc.
- Simplify publish-win-x64.ps1 (drop the -Target Wpf/WinUI switch, there's
only one target now) and rewrite README.md to describe the single-project
layout, build/run/publish commands, and file structure
Verified: dotnet build succeeds for both AmiReel.csproj and AmiReel.slnx, and
the built exe launches and renders identically to before the move.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2.7 KiB
2.7 KiB
description, applyTo
| description | applyTo |
|---|---|
| Performance requirements for data binding, layout, threading, and collection virtualization | **/*.cs, **/*.xaml |
Performance
These rules apply to every feature and change. They are not optional add-ons.
Rules
- Use
x:Bind(compiled bindings) instead of{Binding}— it's faster and type-safe. - Use
x:Load(orx:DeferLoadStrategy) to defer loading of UI elements not immediately visible. - Avoid heavy work on the UI thread — use
Task.Runfor CPU-bound work andasync/awaitfor I/O. - Use virtualizing panels (
ItemsRepeaterwithStackLayout, orListView) for long lists — never useStackPanelwith hundreds of items. - Cache expensive computations and HTTP responses when appropriate.
- Minimize XAML visual tree depth — deep nesting hurts layout performance.
- Use incremental loading (
ISupportIncrementalLoading) for large data sets. - Profile with Visual Studio Diagnostics Tools and PerfView before and after optimizations.
- Be cautious with
DispatcherQueue.TryEnqueue— don't flood the dispatcher queue.
Anti-patterns
- Blocking the UI thread with
.Resultor.GetAwaiter().GetResult(). - Loading all data upfront when only a subset is needed.
- Creating new
HttpClientinstances per request (useIHttpClientFactory). - Using
FindName()orVisualTreeHelperin tight loops.
Validation
- Build & register the MSIX package — see Build, Run & Deploy in
.github/agents/Agents.md.
Verification Checklist
- No blocking calls on the UI thread
x:Bindis used instead of{Binding}- Large lists use virtualization
Must Read & Research
Agent Rule: Before any performance-sensitive change (data binding, layout, collections, async), you must fetch and review these references using
fetch_webpage. Apply what you learn.
| # | Reference | When to consult |
|---|---|---|
| 1 | Performance best practices for WinUI 3 | Any change touching UI rendering, data loading, or threading |
| 2 | x:Bind markup extension | Adding or modifying XAML data bindings |
| 3 | x:Load attribute | Deferring UI element loading |
| 4 | Optimize XAML layout | Restructuring XAML panels, reducing visual tree depth |
| 5 | ListView optimization | Working with lists, collections, or ItemsRepeater |