While the use of an ARM-based platform on desktops quickly became the "next big thing" in the macOS world a while ago, the situation in the Microsoft Windows ecosystem is a bit different. One of the values of the Windows platform is a long retention of established architectures. Due to this, an adoption of a "new" architecture is slower on Windows. Even though Windows on ARM provides emulation for running x64 binaries, there is a performance cost for this. Some of our users ask to provide native support for Windows on ARM (WoA). In this blogpost, you will learn what is available today and get insights on where we want to go.
Current situation
We did quite some work to make Qt run well on WoA. A few things were not trivial. Today, it is possible to use Qt for development and run Qt apps on WoA as a deployment target. This means that applications have to be built using an x64 Windows machine and then deployed to the WoA target. This approach has been in tech preview for a while now, and we still lack several features like proper tooling from Qt Creator and a proper deployment strategy. This is also due to native underlying tooling not providing enablers for us to hook into.
At the same time, this approach is not what most users want when they are using an ARM64 Windows machine. Unlike mobile phones or embedded devices, these WoA machines can be used as development hosts so that the application development itself happens on these machines.
The plan
Instead of supporting WoA as a deployment target, we aim for full support as a development host.
Using ARM64 machines directly to develop the applications is what users want to do.
What you can do today
Building Qt natively for ARM64 is not much different from building Qt for an x64 machine. Having installed Visual Studio 2022 (17.4 or higher) on their ARM64 devices, users can just configure Qt using an ARM64 MSVC developer prompt and build it using ninja.
- Install Visual Studio 2022 (including ninja) and git on your ARM64 machine
- Either open an
"ARM64 Native Tools Command Prompt for VS 2022"or call'"<Path to Visual Studio>\VC\Auxiliary\Build\vcvarsall.bat" arm64'from a cmd shell/Windows Terminal - Clone
git://code.qt.io/qt/qt5.gitinto<Qt Source Dir> - Follow the instructions from our "Building Qt6 from Git" manual
The resulting Qt build can then be used to any Qt applications. qt-cmake.bat from <Qt Install Dir>/bin is a great helper script for that purpose. Just call qt-cmake.bat followed by "ninja/cmake --build" to build your Qt applications.
Using this approach, you can build Qt Creator. You can also install Qt Creator using Qt's official online installers. Doing the latter, you will end up using an emulated Qt Creator, but this should be enough for a quick look on how to use your ARM64 Qt.
In either of these two Qt Creator variants you can just register your Qt version(s) and set the kit(s) accordingly. With that, you should be ready to develop your Qt applications targetting Windows on ARM64 natively.
What is missing?
There might be some minor issues when using Qt Creator on your ARM64 Windows machine, but most functionality should just work.
At the moment, we do not test native WoA packages in our CI infrastructure. We are working on the setup there and hope to give an update on that soon.
As our CI system is also used to build our Qt packages, we do not have native packages for Windows on ARM for installation via the Qt Maintenance Tool right now. This fact should change as soon as the work on our CI system to support WoA builds will be completed.
Last but not least, we are missing native installers for Windows on ARM. As installers are built in CI, the same as with the previous point applies here.
We are still considering whether to use ARM64 or ARM64EC as our "native ARM64 architecture". ARM64EC will probably give more flexibility when it comes to dependencies, and the performance impact might not be too big. We still have to do more research on this topic though. Perhaps we will cover this topic in more detail in an upcoming blog post.
Summary
Qt basically works natively on Windows on ARM. It is usable to build and run native Qt applications for your ARM64 devices but you will have to build Qt yourself. We, the Qt Company, still have some work to do to make the developer experience come up to par with the rest of our offering though.
Commenting for this post has ended.
That looks great, and seems very useful for games that could very well be implemented in Qt (Quick).
Do you have plans to apply FrameAnimation to #QNanoPainter? Or examples showing integration with FrameAnimation?
Is it as simple as replacing the timer-based frame updates with FrameAnimation updates?
Can it be used to improve existing FPS-counters vs https://code.qt.io/cgit/qt/qtmultimedia.git/tree/examples/multimedia/video/qmlvideo/frequencymonitor.cpp?h=6.4 or https://github.com/QUItCoding/qnanopainter/blob/master/examples/qnanopainter_vs_qpainter_demo/qml/FpsItem.qml ?
@Niels Ah, replied already in a tweet with video https://twitter.com/QUItCoding/status/1560876823969517569
The FPS item in QNanoPainter examples (and other places) could be improved with FrameAnimation so that there isn't a need for "dummy animation" to get the animation tickers.
I have been wanting this for a long time, Thanks!. Prevalence of many different refresh rate screens really necessitates a good approach, this is great. Could you please investigate whether the 'frametime' property outputs correct values? When I construct animations which advance a property with realtime like so: FrameAnimation { running: true onTriggered: { panTool.pan(frameTime, 0) } }I am still seeing some jitter in the position of the object I am trying to move. This animation should move the item in a consistent pace according to cumulative time elapsed. Is frameTime being rounded? Most likely it's a performance issue somewhere else on my end but I'm interested in the precision of frameTime
@Felix: Thanks for the comment! I feel you, there has been times when this would have been useful so now took the time to get it into Qt Quick.
Frame time is calculated with https://doc-snapshots.qt.io/qt6-dev/qelapsedtimer.html#nsecsElapsed so theoretical accuracy is nanoseconds, but the actual resolution depends of course on the platform. It is time in seconds since previous animation ticker, so contains some fluctuation from 0.016666.. (on 60Hz screen). When there is a need for more stable values you can use smoothFrameTime property which on my Windows laptop now gave values like:
qml: smoothFrameTime: 0.01668457919031026 qml: smoothFrameTime: 0.016695221271279235 qml: smoothFrameTime: 0.016690869144151313 qml: smoothFrameTime: 0.01667907222973618 qml: smoothFrameTime: 0.016702725006762564 qml: smoothFrameTime: 0.016691022506086308 qml: smoothFrameTime: 0.01669270025547768 qml: smoothFrameTime: 0.016695180229929912 qml: smoothFrameTime: 0.01668765220693692 qml: smoothFrameTime: 0.016689826986243227 qml: smoothFrameTime: 0.016676244287618904 qml: smoothFrameTime: 0.016666089858857015 qml: smoothFrameTime: 0.016666790872971314 qml: smoothFrameTime: 0.016666261785674184 ...@Marcin Thanks! Yes, useful for games and game-like UX where you need more freedom for animations.