win2d-development

Use CanvasControl for mostly static or event-driven drawing where you call Invalidate() when a redraw is needed. Use CanvasAnimatedControl for continuous animation or game-style update/draw loops, since it provides a dedicated render thread and timing information.

Treat device loss as a normal lifecycle event. Recreate the device and all dependent resources via CreateResources, detect failures with CanvasDevice.IsDeviceLost, and never keep using bitmaps, render targets, or effect graphs tied to the old device.

Use the Microsoft.Graphics.Win2D package for WinUI 3 / Windows App SDK projects. Do not use the older Win2D.uwp package, and avoid copying UWP-era code snippets without validating namespaces, threading, and lifecycle behavior.

Common causes include per-frame GPU resource creation, repeated bitmap decoding, unbounded allocations, excessive offscreen intermediates, and fill-rate limits at high DPI. Profile first, then cache stable resources, batch sprites, and reduce redundant invalidation.

No. The Update and Draw callbacks run on a game-loop thread, not the UI thread. Publish immutable snapshots or small synchronized state from the UI thread instead of reading XAML objects directly, and never block inside these callbacks.

B8G8R8A8UIntNormalized with premultiplied alpha is the safe default for most 2D content. Verify support on CanvasDevice before choosing HDR, floating-point, or other exotic formats, and never feed straight-alpha data into premultiplied surfaces.