Porting your WPF app to run on Arm with UWP

Windows has several frameworks with which to design windows applications. The newest of these is the Universal Windows Platform (UWP), which allows for an application to be deployed on many supported platforms, including AArch64. Since older platforms such as Windows Presentation Foundation (WPF) do not support Arm-based Windows devices yet, I made an application in WPF. After I made the application in WPF, I then converted it to UWP, to show the benefits of running applications natively on Windows on Arm (WoA). 

Application description

The application is an image manipulation app and is reasonably straightforward: An image of a frog is displayed, this image is arbitrary but has quite a good range of color in it. As the user moves their cursor over the image, the colours of the image’s pixels are changed. The intensity of this change is on a per pixel basis, and scales based on the distance from the pixel to the cursor position. Several options for intensity of the change are available with a radio button set. The following images show before and after the mouse is moved over the image.

The porting and recreation process

I originally made the app in WPF. This was relatively straightforward, as the application is not too complex. I then attempted to port the application to UWP. This caused complications, not least due to the UWP framework using a very similar set of class names to WPF, but with differing functionality and use. This meant the “port” was more of a recreation of the application function, rather than just minor changes. The other major complication was UWP requiring data to be streamed into the pixel buffer of the image, rather than allowing direct modification the way WPF does.

The following is the difference between the two frameworks when loading the new byte data into the pixel array:

WPF:

BitmapSource bitmap = BitmapSource.Create(width, height, 96, 
       96, pf, null, rawImage, rawStride);
 
img.Source = bitmap;

UWP:

WriteableBitmap bmp;
Bmp = new WriteableBitmap(width, height); 
using (Stream stream = bmp.PixelBuffer.AsStream())
{
     stream.WriteAsync(rawImage, 0, rawImage.Length);
}                
img.Source = bmp;

As shown, the WPF framework allows direct manipulation of the data, whereas UWP requires the data be streamed into the new bitmap image. This is not only slightly less intuitive to write in UWP, it also runs the instruction as an asynchronous task. This action alone might slow down the application on slower CPUs with weaker threading capabilities.

Deployment

WPF allows you to simply place the executable and asset files in a folder and it launches without much issue – the caveat being that assets must be declared in Visual Studio. Conversely, UWP requires that the application be deployed by an installer or Visual Studio during debugging to run without issue - side-loading is not supported.

In the WPF method, where “frog.bmp” is set to Resource in Build Action, which allows the application to load the content correctly at runtime. As mentioned, UWP does not require the developer to tag content in this manner.

Performance improvement

Due to UWP running natively, there is less overhead than the emulated WPF application, which results in a lower amount of computer resources being used. Shown in the following image are the performances of both apps running on a Windows on Arm machine (Samsung Galaxy Book). As shown, both applications use similar amounts of CPU resources. The WPF application uses about 9-10 times more memory to run compared to the UWP application. The applications’ CPU use is similar – presumably due to the mouse event polling rate triggering events at the same rate across both applications. Unfortunately, there is no way to sideload an x86 UWP app onto the WoA device, so direct UWP emulated and native comparisons could not be made.

WPF application:

Note that the task manager lists this application as 32-bit, which is a result of the emulation layer running both 32-bit and 64-bit applications in 32-bit.

UWP application:

Conclusion 

Overall, differences between the frameworks were the main challenge during the porting process. The UWP framework has a secure way of loading assets, which cause it to be much more memory efficient. This can be at the cost of some of the gains most applications would see when moving to native. However, it would be wise to consider the advantages of UWP before porting from WPF, as WPF has received native WoA support in the July NET5.0 release.

Windows on Arm resources

Sign up to the Arm DevSummit technical sessions where you will learn more about developing, deploying and debugging for Windows on Arm .

Sign up to Arm DevSummit