[AsafMah]

Description

Adds TableView.StarColumnResizeDelay (a TimeSpan, default zero, which keeps today's behavior).

When the TableView's width changes, star columns are recalculated, and every realized cell in them lays out again. While the user resizes the window, that happens on every frame. I measured it in an app with ~300 rows and a star Name column, timing UI-thread turnaround per window-resize step against Notepad on the same display:

• with the star column: ~15-20 ms per step above the baseline;
• the same column at a fixed width: no measurable cost above the baseline.

With a delay set, star columns keep their width while the size keeps changing and recalculate once it has paused for that long. With 120 ms, the app resized at the baseline cost. The first layout and fixed-width columns don't wait.

Related Issue

None opened.

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 📝 Documentation update
• ♻️ Refactor
• 🧪 Test
• 🔧 Chore / maintenance

Checklist

• This PR is not from my main branch
• Tested with WinUI target (in an app, measured as above)
• Tested with Uno Platform target (not tested; the change is in shared code)
• Unit / integration tests added or updated (none added; the existing suite passes locally except SelectingARowWithWideDetails_KeepsTheSelectionVisualsOnTheCells, which also fails on main on my machine)
• Documentation updated to reflect changes (column-sizing.md)
• Code follows the project's coding conventions

Additional Notes

A gap or horizontal scroll bar can show briefly during the drag, which is why it's opt-in.

🤖 Generated with Claude Code