Expose high-level APIs to create CanvasSwapChain-s for HWNDs about win2d HOT 5 OPEN

Notes from API review

Looks good as proposed.

namespace ABI {
    namespace Microsoft {
        namespace Graphics {
            namespace Canvas {

              class __declspec(uuid("040AB731-08F1-469F-9BF9-5B1160F27224"))
                  ICanvasSwapChainFactoryNative : public IUnknown
              {
              public:
                  IFACEMETHOD(CreateForHwnd)(
                      ICanvasResourceCreator* resourceCreator,
                      HWND hwnd,
                      uint32_t width,
                      uint32_t height,
                      float dpi,
                      DirectXPixelFormat format,
                      int32_t bufferCount,
                      ICanvasSwapChain** canvasSwapChain) = 0;
              };
} } } }

namespace Microsoft.Graphics.Canvas;

public sealed class CanvasSwapChain
{
    public static CanvasSwapChain CreateForHwnd(
        IntPtr hwnd,
        uint width,
        uint height);

    public static CanvasSwapChain CreateForHwnd(
        IntPtr hwnd,
        uint width,
        uint height,
        DirectXPixelFormat format,
        int bufferCount);
}

The C# APIs added to CanvasSwapChain will use GetDpiForWindow to set the initial DPI value. It is up to developers to then monitor DPI changes (through WM_DPICHANGE) and call the appropriate Resize overload to update the DPI value. This matches the general behavior of CanvasSwapChain when used with composition or CoreWindow as well. Additionally, CanvasSwapChain as a whole is meant to be a lower-level helper API anyway. The new APIs introduced in this proposal will already make it significantly easier for developers to get a swapchain running on a raw HWND. For those needing more control over how the swapchain is created, they can keep using the existing approach of manually creating the swapchain and then using GetOrCreate from the CanvasDevice activation factory interop interface to get the WinRT wrapper for it.

from win2d.

Can't you retrieve the window DPI with GetDpiForWindow?

from win2d.

Right, we could use that to automatically get the initial DPIs, and remove the dpi parameter form the static constructors, that'd work nicely. The only thing I'm not exactly sure how to handle is the fact the effective DPI might change after creating the swap chain (eg. if you move the window to another screen with a different DPI, or if you change the DPIs on your screen), but the swap chain wouldn't really respond to that, and its internal DPI value would become "out of sync".

Should we just not worry about this scenario? Users are still able to override the DPI value by calling the Resize overload, is that enough? As in, they could detect a DPI change on their end, and then call Resize with 0 for width and height, and the right value for the new DPI. The swap chain would resize automatically and then update the internal DPI value.

Maybe that's sufficient? 🤔

from win2d.

You could subclass the window to capture the WM_DPICHANGE message. Am I understanding correctly that Win2D tracks its own DPI values?

from win2d.

I guess it does when you use higher level objects that handle that for you (eg. CanvasAnimatedControl, which is a wrapper around CanvasSwapChain, which subscribes to DPI changes automatically). Double checking things, CanvasSwapChain does not in fact handle this automatically, as it's meant to be a lower level object, so I guess that makes sense. If you want to update DPIs you can just monitor DPI change events on your own and call Resize on the panel when needing, and pass the new DPI value from there to update it. It seems like that should be enough. 🤔

from win2d.