reactor-advanced
Skill839 starsChanged 6 days agoMITView on GitHub
Reactor.Advanced Win2D canvases — choosing Win2DCanvas, Win2DAnimatedCanvas, or Win2DVirtualCanvas; using UseDrawState, UseCanvasResources, UseDrawCommand; and following threading/device-loss rules.
In this repository23 other files it gives its agents.
- AGENTS.mdAGENTS.md
- analyzer-dymSkill
- coverage-upliftSkill
- perf-compareSkill
- pr-lifecycleSkill
- pr-reviewSkill
- reactor-asyncSkill
- reactor-build-and-checkSkill
- reactor-chartsSkill
- reactor-commandingSkill
- reactor-designSkill
- reactor-devtoolsSkill
- reactor-dockingSkill
- reactor-dslSkill
- reactor-formsSkill
- reactor-getting-startedSkill
- reactor-inputSkill
- reactor-navigationSkill
- reactor-recipesSkill
- reactor-windowingSkill
- reactor-wrappingSkill
- reactor-appSkill
- ChartingSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Use this skill when adding immediate-mode Win2D drawing through Microsoft.UI.Reactor.Advanced.
- Very specific: line 27
Treat Ref.Current from UseDrawState like a volatile field.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Reactor Advanced
Use this skill when adding immediate-mode Win2D drawing through Microsoft.UI.Reactor.Advanced. The full guide is docs/guide/win2d-canvas.md; the performance sample is samples/apps/particle-storm/.
Pick the right canvas
| Workload | Use | Why |
| Static or data-driven drawing that changes after state updates | Win2DCanvas.Of(onDraw, redrawKey) | Manual invalidation; pass a changing RedrawKey for every value the draw callback reads. |
| Game loop, physics, particles, visualizers, steady FPS | Win2DAnimatedCanvas.Of(onUpdate, onDraw, drawState, isPaused) | Win2D owns the tick and calls update/draw on the game thread. |
| Huge scrollable or tiled surfaces | Win2DVirtualCanvas.Of(onRegionDraw, contentSize) | Draws only invalidated visible regions; update tiles by changing InvalidateRegions. |
Threading cheat sheet
| Callback | Thread | Rule |
Win2DCanvas.OnDraw | UI thread | Safe to read Reactor state captured by render. |
Win2DAnimatedCanvas.OnUpdate / .OnDraw | Win2D game thread | Do not touch WinUI controls. Use thread-safe data or UseState(threadSafe: true) for UI handoff. |
Win2DVirtualCanvas.OnRegionDraw | UI thread | Keep work bounded to the invalidated region. |
UseCanvasResources factory | Worker/game thread | Create device resources and return a disposable/recreatable object. |
Treat Ref.Current from UseDrawState like a volatile field. Re-read it and make the referenced object safe for any cross-thread mutation. Debug builds add a sentinel that appends docs/guide/win2d-canvas.md#threading to likely WinUI thread-affinity exceptions from animated callbacks.
Reference graph model
Element refs are reactive cells. .Ref(cell) writes the mounted
FrameworkElement into the cell and writes null on unmount.
Reference properties (TeachingTip.Target, .LabeledBy, .DescribedBy,
.FlowsTo, .FlowsFrom, .XYFocus*, and custom descriptor
.Reference / .ReferenceList) subscribe to those cells instead of
sampling .Current.
Resolution is one-way and push-based: cells enqueue dirty reference
edges during commit, then Reactor flushes the dirty set after the tree is
stable. Cycles are allowed because each property slot is a one-way edge.
List references preserve author declaration order and omit unresolved
targets. Advanced authors should use descriptor.Reference for regular
controls and binding.Reference only as the bridge for hand-coded
handlers.
Hooks and recipes
var state = ctx.UseDrawState(() => new ParticleField(20_000));
var sprite = ctx.UseCanvasResources<CanvasBitmap>(async device =>
await CanvasBitmap.LoadAsync(device, "Assets/particle.png"));
var draw = ctx.UseDrawCommand(model, static (session, args, m) =>
m.Render(session), deps: [model.Version]);UseCanvasResources is the device-loss recipe: allocate from the supplied CanvasDevice, draw only when the returned ref is non-null, and let the hook dispose/recreate after CanvasDevice.DeviceLost.
Performance proof
The Particle Storm sample (samples/apps/particle-storm/) is the canonical pattern: pure Reactor chrome controls parameters; Win2DAnimatedCanvas renders the hot particle path; UseDrawState holds the particle buffers; UseCanvasResources owns sprites and other device resources.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

