UWP app crashes when a big CanvasControl is created.

[gsantopaolo]

Step to reproduce the issue:

• Create a new blank UWP app targeting CU.
• Add a nuget package reference to Win2D.uwp
• add the followin xaml into the MainPage.xaml

`

    <InkCanvas Grid.Column="1" x:Name="inkCanvas"/>
</Grid>`

If you run the following app on a PC with a screen resolution of 1920x1080 at 96 dpi it works If you run the following app on a PC with a screen resolution of 3200x1800 at 168 dpi it crashes If you run the following app on a PC with a screen resolution of 2736x1824 at 192 dpi it crashes

By decreasing CanvasControl's width and height it does not crash any more. As you can understand when you develop a UWP application we target from small 4 or less inches all the way up to 84 inches with an unpredictable combinations of resolutions / dpi

A possible workaround for this issue should be to set the ForceSoftwareRenderer CanvasControl's property to True, but this is not acceptable when using the CanvasControl related to Ink because the ink experience becomes extremely lagging and far away of giving users a more personal experience.

All that said, is there a formula so it is possible to determine the maximum CanvasControl width and height based on screen resolution / dpi / (MaximumBitmapSizeInPixels) so that the application won't miserably crash?

Is there any chance that this behavior will change in the future?

Thanks a lot Gian Paolo

[damyanp]

This article covers the relationship between DIPS, pixels and DPI: http://microsoft.github.io/Win2D/html/DPI.htm

In your examples:

• 96 DPI: 1 DIP = 96 / 96 = 1 pixel
• 168 DPI: 1 DIP = 168/96 = 1.75 pixels
• 192 DPI: 1 DIP = 192/96 = 2 pixels

So in the 168 DPI case you're asking for a CanvasControl that's backed by a 17,500 x 10,500 pixel image source. MaximumBitmapSizeInPixels is likely to be around 16384, which explains this fails.

You can use a CanvasVirtualControl to support larger, virtualized surfaces.