此测试发现了 WPF 的渲染非常跟输入，而 Avalonia 显着掉队
在我的测试用例内里，特别让 Avalonia 窗口去吸收输入，让 Avalonia 驱动 WPF 的界面。云云可以扫除 Avalonia 的输入层带来的耽误。完全只对比 Avalonia 和 WPF 的渲染层
具体请参阅： https://github.com/AvaloniaUI/Avalonia/discussions/20562
实行情况如下图所示，蓝色为 Avalonia 的控件，赤色是 WPF 的控件
本次测试用的 Avalonia 版本为 11.3.11 版本
具体实行计划如下：
- 新建 WPF 和 Avalonia 空缺项目
- 分别在 WPF 和 Avalonia 项目标界面添加差别颜色的 Border 控件。且附加上 TranslateTransform 到 Border.RenderTransform 属性上，用于让 Border 控件被移动
- 让 WPF 窗口配景透明，且通过 GWL_HWNDPARENT (SetOwner) 让 WPF 窗口表现在 Avalonia 窗口之上。云云运行项目可在同一屏幕上看到 Avalonia 和 WPF 框架的两个窗口，此中 WPF 窗口作为透明窗口叠加在 Avalonia 窗口之上
- 在 Avalonia 框架内监听 Pointer 的按下和移动，当移动的时间设置 Border 的 TranslateTransform 的 X 坐标。随后将此坐标变动发送给到 WPF 应用，让 WPF 应用内的 Border 也做雷同的 TranslateTransform 变动
- 离开 Visual Studio 独立运行项目，利用鼠标或触摸移动 Border 控件
本文所采取的测试代码放在 github 和 gitee 上，可以利用如下下令行拉代替码。我整个代码堆栈比力巨大，利用以下下令行可以举行部分拉取，拉取速率比力快
先创建一个空文件夹，接着利用下令行 cd 下令进入此空文件夹，在下令行内里输入以下代码，即可获取到本文的代码- git init
- git remote add origin https://gitee.com/lindexi/lindexi_gd.git
- git pull origin 3f38106c92a2a645e0df7b27731b5f84f3e16f78
- git remote remove origin
- git remote add origin https://github.com/lindexi/lindexi_gd.git
- git pull origin 3f38106c92a2a645e0df7b27731b5f84f3e16f78
答复一些迷惑：
- 按照以上的实行计划，输入层是从 Avalonia 框架来的，意味着 Avalonia 在输入处置惩罚方面还比 WPF 实行得更早。至少 WPF 须要等待 Dispatcher 调理之后才气收到输入
- 无论是 WPF 照旧 Avalonia 框架，都实行了雷同的上层逻辑代码，都通过 RenderTransform 举行变动
- 为什么不利用动画而是利用输入来测试？由于 WPF 和 Avalonia 的动画模块有很大的实现差别，为了控制变量，选择利用输入来做
- 选择让 WPF 窗口是透明的，云云可以让 WPF 框架负担透明窗口带来的更多渲染代价。在 WPF 框架遭受了透明窗口渲染代价的条件下，依然可以或许轻松领先于 Avalonia 框架，云云更可阐明 Avalonia 框架的渲染耽误性
- 在实际实行中，在 4K 分辨率的触摸屏上，可以或许感受到更大的差别，可见 Avalonia 更掉队于 WPF 框架
- 是否设置 Avalonia 利用 LowLatencyDxgiSwapChain 可以或许办理此题目？设置 LowLatencyDxgiSwapChain 只能缓解题目，但依然在渲染耽误上掉队与 WPF 框架
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |
发表于 2026-2-6 12:51:08