|Interop with Direct2D||
Win2D is implemented as a layer on top of
and supports interop in both directions. If you have a Win2D object, you can
access the native Direct2D object that is used to implement it. If you have a Direct2D
object, you can look up the Win2D object that wraps it, or create a new wrapper
if one did not already exist.
Apps occasionally need to draw graphics to a target, where that
target is not intended for immediate
display. This type of drawing is sometimes called "offscreen
rendering", or "drawing to a texture".
This is useful when, for example, an app's output of a drawing
operation is to be saved to a file, returned as an array of pixels,
or used as an input to a later operation.
|DPI and DIPs||
This article explains the difference between physical pixels and device
independent pixels (DIPs), and how DPI (dots per inch) is handled in Win2D.
|Choosing control resolution||
This article explains how to configure the resolution used by
Win2D's XAML controls. It explains how to:
Make Win2D controls run at a fixed resolution.
Adjust control DPI to improve performance by rendering fewer pixels.
enum includes all the many and varied pixel formats used by Direct3D and DXGI,
but only a few of these options are supported by Win2D (or by Direct2D upon which
Win2D is built).
In computer graphics there are two different ways to represent the opacity of a
color value. Win2D uses both methods. This article explains the difference, and
which is used where.
|Bitmap block compression||
CanvasBitmap supports block compressed bitmaps. These can be loaded
from a DDS file, or created with
CreateFromBytes(ICanvasResourceCreator, Byte, Int32, Int32, DirectXPixelFormat).
|Effect precision and clamping||
Care must be taken while rendering effects using Win2D to achieve the desired level of
quality and predictability with respect to numerical precision.
|Handling device lost||
"Device lost" refers to a situation where the GPU graphics device becomes
unusable for further rendering. This can occur due to GPU hardware malfunction,
driver bugs, driver software updates, or switching the app from one GPU to
another. A lost device can no longer be used, and any attempt to do so from
Win2D will throw an exception. To recover from this situation, the app must
create a new device and then recreate all its graphics resources.
|Using Win2D without built-in controls||CanvasControl,
are XAML controls- they extend UserControl and can exist alongside
other controls in an app's XAML tree. They are good choice for many WinRT
apps that use XAML and produce graphical content using Win2D. While
these controls are versatile, they do impose policies pertaining to
layout, resource re-creation, and device lost. Apps may want to
implement their own XAML controls, or not use XAML at all.
|Loading resources outside of CreateResources||
This document discusses how apps using Win2D's XAML controls,
CanvasControl, CanvasVirtualControl and CanvasAnimatedControl, can
load resources from outside the CreateResources handler.
|Avoiding memory leaks||
When using Win2D controls in managed XAML applications, care must be taken to
avoid reference count cycles that could prevent these controls ever being
reclaimed by the garbage collector.