学习
实践
活动
工具
TVP
写文章

WinUI 3 Preview 3 发布了,再一次试试它的性能

首先用和 《WinUI 3 试玩报告》同样的代码在 Preview 3 进行了测试,结果如下: CPU 内存 GPU WPF .NET Framework 4.8 12 60 76 WPF .NET 这次找到最近写的 《使用离散式关键帧播放动画》里的散步猫动画。 1920 * 1080 分辨率,100%拉伸 Windows 10 20H2 测试结果如下: CPU 内存 GPU WPF .NET Framework 4.8 3 177 21 WPF .NET ,是不是撸不起? UWP:表现也优异了吧,可能是的错觉?不过 UWP 也并不是没有问题,只要猫的数量再多些就会报 “Layout cycle detected.

50220

UWP 和 WPF 对比

这时不要说 IL 可以针对每个 CPU 做优化,因为 dot net core 编译的代码就是对不同的 CPU 做优化。如果还需要对特殊CPU做优化,还没找到。 但是现在有 Avalonia 和 Xamarin WPF,这两个都是可以支持很多平台,如 mac 和 Linux ,需要说的是,一个在开发 Xamarin 的小伙伴说,WPF 是一个恐怖的工程,他不觉得很快就可以把 组合的图形和动画通过 DirectComposition 构建然后传到 DWM 渲染到屏幕。所以使用 DirectComposition 不需要特殊的渲染框架。 但是在 UWP ,没有源代码,而且难以反编译,如果遇到坑都不知道是不是微软的代码写的。 成熟 WPF 是比较成熟的,现在已经有 10 多年,有很多库,而且遇到的问题基本都有人遇到。 对于 UWP ,是比较不成熟,很多功能没有。 参见:UWP vs.

19020
  • 广告
    关闭

    年末·限时回馈

    热卖云产品年终特惠,2核2G轻量应用服务器6.58元/月起,更多上云必备产品助力您轻松上云

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    UWP 和 WPF 对比

    这时不要说 IL 可以针对每个 CPU 做优化,因为 dot net core 编译的代码就是对不同的 CPU 做优化。如果还需要对特殊CPU做优化,还没找到。 但是现在有 Avalonia 和 Xamarin WPF,这两个都是可以支持很多平台,如 mac 和 Linux ,需要说的是,一个在开发 Xamarin 的小伙伴说,WPF 是一个恐怖的工程,他不觉得很快就可以把 组合的图形和动画通过 DirectComposition 构建然后传到 DWM 渲染到屏幕。所以使用 DirectComposition 不需要特殊的渲染框架。 但是在 UWP ,没有源代码,而且难以反编译,如果遇到坑都不知道是不是微软的代码写的。 成熟 WPF 是比较成熟的,现在已经有 10 多年,有很多库,而且遇到的问题基本都有人遇到。 对于 UWP ,是比较不成熟,很多功能没有。 参见:UWP vs.

    9.4K20

    APP-hybrid页面性能测试的一些知识记录

    这里根据上报情况看,fetchStart和客户端给的绝对初始时间差距并不大。 如果需要测试页面滚动的fpscpu、内存使用情况该怎么办嗯?只能借助一些小工具来完成本地测试。 帧方差就是FPS序列的方差,越小,说明页面滚动越平滑。 FPS黑盒测量 android7.0以下的手机可以用Emmagee软件来进行测试。非常方便,每秒统计一次,直接生成csv以待分析。 能不能统计一下,是不是和ios的版本有关呢? R更多的是一个方便的表单数据处理工具,用来分片、筛选、算总数、平均、方差等等常用的操作实在方便了。伴随着你的思考,几条命令就可以实现了。用熟悉了是很节省时间的事情。

    1.3K00

    Android界面性能优化必读

    引起掉帧的原因非常多,比如: 花了非常多时间重新绘制界面中的大部分东西,这样非常浪费CPU周期; 过度绘制严重,在绘制用户看不到的对象上花费了太多的时间; 有一大堆动画重复了一遍又一遍,消耗 CPU动画的显示更加复杂,我们需要在 16 ms 内处理完所有 CPU 和 GPU 的计算、绘制、渲染等操作,才能获得应用的流畅体验。 二. 使用这个工具可以让你查看在动画期间哪些不期望更新的布局有更新,方便你进行优化,以获得应用更好的性能。 给开发的界面优化 Advice ------------------ 6.1 优化布局的结构 布局结构复杂,会减慢渲染的速度,造成性能瓶颈。 官方详解 「 戳 」 使用 merge 标签减少布局的嵌套层次,官方详解 「 戳 」; 去掉多余的不可见背景。

    36010

    也许,DOM 不是答案

    一、Web App vs. Native App 比起手机App,网站有一些明显的优点。 主要是互动(interaction)和动画(animation)这两方面,会出现卡顿(jank),用户会感觉到明显的时滞,有时简直慢得难以忍受。 Web app的性能瓶颈,主要有以下原因。 浏览器重绘网页的频率是60FPS(即16毫秒/帧),JavaScript做不到在16毫秒内完成DOM操作,因此产生了跳帧。用户体验上的不流畅、不连贯就源于此。 (3)网页是单线程的。 网页都是由CPU处理的,没用GPU进行图形加速。 上面这些原因,对于PC还不至于造成严重的性能问题,但是手机的硬件资源相对有限,用户互动又相对频繁,结果跟Native app一比,就完全落在了下风。 在文中,James Long对未来的Web app提出了几点预测,认为很值得分享。 (1)多线程浏览器。

    41250

    开发者选项详解

    渲染模式分析:的手机还流畅跟手吗? 做完这个简单的操作,你会发现,手机运行速度会提高了不少。 ? 由于GPU在处理图形方面比CPU更快且效果更好,强制使用GPU渲染会充分地利用你手机的GPU,开启该功能之后可以大大降低CPU使用率,减轻CPU的负担,这样会让Android手机运行一些应用程序时更为流畅 在一个论坛中偶然看到有人说,可以通过“显示布局边界”来判断这个界面或者某个部位是不是html5实现,只想说,好机智。 ? 强制进行GPU渲染 这个选项的意思就是强制开启硬件加速。 绿色的横线表示每一帧渲染时间的阈值,值为16ms,这是因为Android流畅运行的帧率为60fps,如果每一帧的渲染时间超过16ms,帧率就降低到小于60fps,会出现丢帧的情况,直观的感受就是页面出现卡顿

    4.5K10

    PFLD:简单、快速、超高精度人脸特征点检测算法

    PFLD算法,目前主流数据集上达到最高精度、ARM安卓机140fps,模型大小仅2.1M! 与精度差别很小的LAB算法相比,CPU上的速度提高了2000倍! 下面是一些特征点检测示例,尽管很多样本难度很大,但PFLD依然给出了可以接受的结果。 ? ? 这个算法实在是吸引人了,你是不是也想试一下呢? 作者给的网址: https://sites.google.com/view/xjguo/fld 在“爱计算机视觉”公众号对话界面回复“PFLD”即可收到下载地址。 (CV君下载了APK试用,好像没看到效果,不知是不是手机兼容性有问题) 提醒一下,作者声明,该工程仅可用于研究比较,如需商业使用需要联系作者获得授权。

    76520

    Canvas 动画引擎解析与微信小程序中的应用

    WebGL的优点是,支持3D,在3D下做得是非常好的,官方宣称它的性能非常高,但实际上从使用的各种基于WebGL的东西来看,它耗资源是非常多的,消耗CPU和内存都很多。 Google Earth是可以调出WebGL的引擎的,它支持3D的场景的渲染,你可以打开任务管理器去看,实际上你一旦开始用这些基于WebGL的东西,就会发现你的CPU或者显卡的使用率就会上去。 三、人们一直在追求 60 fps 的极致体验 先说一下基本的动画的过程。 例如,给他一个16,假装这个地方能做到60FPS,实际上是达不到的,这实际上是有问题的,JS脚本动画,首先它有性能比较差的毛病,有两个原因导致的。 对象本身的渲染的过程和动画的过程能不能解开,让它更好一些,回头再看是不是能找到一个更好的设计的思路,但目前来看这个还是实现得不错。

    84130

    「玩转树莓派」搭建智能家居远程监控系统

    ) 在开始之前照常先秀一下这半成品的监控系统,是不是丑到爆!? 不得不说,真的很耗CPU,差不多持续在60%左右,并且有一定的延迟,卡顿特别严重。 ,也就是按一下/键,然后输入fps,然后回车将fps、高度、宽度修改,参考下图: ? 869c7994c40b84ac09f244f768db9269d52d3265d376441e8516a47f24711ef2 这可能是由于网速太慢了,没有下载完整的文件,所以不完整的文件的md5和期望的不一样 有点小遗憾的是,启动脚本后,Python 进程 CPU 占用率居然高达300+,平均每个 CPU 差不多80+的样子,心疼的小风扇一秒钟。

    1.6K10

    活久见!Arm居然为Cortex-M发布了专属显卡驱动

    于是你也很快提供了对应的GUI产品,但问题随之而来: 市面上完全没有针对单片机的第三方2D类跑分软件…… 与Cortex-A以及Linux环境较为规范的软件环境不同,深度嵌入环境碎片化严重了: LCD 芯片厂家:你只要按照的标准为你的2D加速引擎写好驱动就行了——分分钟获得所有以Arm-2D作为底层的GUI的支持; GUI提供商:但凡你GUI中需要用到硬件加速的地方,都可以直接调用提供的API就行了 让不同的图层以不同的速度和角度飘来飘去以覆盖更多可能的情况——模拟日常GUI中可能出现的不同复杂度; 渲染1000帧,记录下每一帧所消耗的CPU时钟周期数,并提供最小值、最大值和平均值等信息。 考虑到作为面子工程的LCD屏幕其实也并不太贵——如果能用彩屏实现类似智能手机界面(没有动画)来提升逼格,那产品的竞争力肯定是“岗岗”的。 是不是惊呆了? 例子工程在 “main-arm-2d-more-example” 分支下的example目录中可以找到。 【Arm-2D库怎么用呢?】

    53650

    Unity基础教程系列(新)(六)——Jobs(Animating a Fractal)

    1.6 性能 让分形产生动画是一个不错的主意,但它也应该足够快地运行。分形深度小于六分应该没问题,但是分形深度高可能会成为问题。因此,分析了一些构建。 ? 帧速率有了巨大的提高,RP均达到深度7的140FPS,深度8也均达到30FPS。更新时间也减少了。这可能是因为在渲染球体时设置缓冲区数据更加耗时,因为CPU被迫等待,直到GPU从缓冲区中读取完成。 最大值约为32FPS,因此CPU是渲染立方体时的瓶颈。幸运的是,我们可以采用其他方法,即Unity的事务系统(Jobs System)。 因此,仅通过启用Burst编译,我们的更新速度就提高了一倍以上。我们仍然仅使用单个CPU内核,因此加速完全是由于Burst应用的优化。 您可能会注意到,刚进入播放模式后,性能会差很多。 进行此更改后,的平均更新持续时间降至4.5毫秒。因此,仅通过存储和传输较少的数据就获得了毫秒的收益。 4.10 使用多核 我们已经达到了单个CPU内核的优化终点,但是我们可以走得更远。

    68031

    闫燕飞:Kafka的高性能揭秘及优化

    但同时我们也发现Kafka Broker在测试中,的CPU使用率,尤其是磁盘I/O使用率并不高,说明社区Kafka还是有一定的优化空间。 那么这样是不是说我们整个Kafka就没有任何的优化空间了? 我们期望通过该优化不仅能有吞吐方面的提升,更重要的是期望在类似的场景下,可以更好的减少资源的使用率,进一步缩减成本。 QA Q:这里需要请教你一个问题,就是看刚才看到一部刷盘优化的时候,发现CPU也是随着性能的提升上升了很多倍,这里是不是主要是因为优化过程中你又做了一次拷贝? 这么多消耗的叠加当然照成CPU使用率数倍的提高也是很正常的。

    2.8K270

    关于计算机图形学与技术美术

    千万级构建的三维模型所需的最低硬件需求; 前后端通讯的接口逻辑; ---- 核心目标 三维可视化研发在今年的目标主要是做成一个初版的demo,实现从空间索引数据库PostGIS中动态加载构建(三角面片总量是10亿数量级的期望 ---- 自我提升方向 2021年的提升方向大致是沿着TA这条主干路线走,深入研究网格建模与图形理论,学习GLSL着色器语言和Direct3D图形卡接口,实现骨骼动画和基于shader的特效 明年上半年的主题无疑是性能优化,优化的内容包括: 选择主频更高的服务器cpu以加速渲染; 减少FoV角度以限制视锥体内的三角数量; 限制帧数在25~35fps以兼顾性能和流畅性; 最大化空间检索的能力以保持 按照目前的研发速度,明年下半年以后大多关键技术瓶颈都已经迎刃而解,同时还伴随着UE5的正式发布,届时动态的全局光照和层次细节将被原生支持,空间索引和即时渲染的难度将大大降低,引擎的整体性能会发生质的升级,当然也不能依赖新技术 :软件层面的更新迭代不可能超越硬件的极限,从CPU、GPU、内外存、带宽的角度思考功能、性能、安全性始终是明智的研发思想。

    45620

    dotnet 代码调试方法

    if (foo) { // 执行某段逻辑,但是这段逻辑没有按照期望被运行 } 此时应该通过断点,将断点放在判断这句话 添加断点方法 添加断点有很多方法 在需要调试的代码里面,将光标定位到需要调试的代码这一行 但是有很多逗比的开发者会写出逗比的代码,期望让他在开发的时候就发现,于是就通过了判断当前是 DEBUG 版还是发布版执行不同的逻辑 例如在希沃白板软件加载课件的过程,每个课件里面都有不同的页面,如果某个页面加载出现异常 ,期望用户整个课件都打不开,于是就吃掉了页面加载的异常。 但是页面是很多小伙伴写的,期望在开发的时候小伙伴就能发现这里有异常,通过下面的代码区分了发布版 static void Foo() { #if DEBUG 因为不知道这段界面的动画代码是写在哪,也不知道这里是不是有逗比改了动画还是有逗比修改了逻辑让动画不触发 这时就进入了无异常调试,虽然很多时候还是可以打断点的,但是因为代码太多也很难知道从哪里开始进入断点

    76510

    用机器学习加速你的网站

    一生中大约73%的时间都在思考网络性能:如何在慢速手机上能播放60FPS的画面,用完美的顺序加载资源,通过离线缓存能做的一切。等等等等。 但最近一直在想,对Web性能定义是否狭隘了。 当用户在网站上发帖出售东西时,他们要先选择物品的类别,选择期望的广告包,填好细节内容,然后预览广告内容,最后发布这个广告。 第一步:选择一个类别,就把带坑里了。 首先, 这里一共有674个类别。 这件事大概花了4个多小时,一半的时间花在调通这个脚本上。 把得到的CSV上传到S3上去,然后按着教程又建了新的模型,再训练。总共消耗的CPU时间是3分钟。 买手套的钱都比这多。 每条预测结果也收费,大概是$0.0001。所以,你懂的,别做随机的预测。 当然了,不只是Amazon提供这些好货,只是没从别人那找到更便宜的。 制作酷炫无比的无穷隧道特效 一个治愈JavaScript疲劳的学习计划 全栈工程师技能大全 WEB前端性能优化常见方法 一小时内搭建一个全栈Web应用框架 干货:CSS 专业技巧 四步实现React页面过渡动画效果

    35320

    app的测试点_测试皮肤的软件叫什么

    性能测试:这部分分为两个方面,一部分是后台服务的性能测试(API的响应时间和响应报文大小),一部分是应用自身的性能情况(占用CPU、内存、I/O、电量情况,以及页面到页面之间的切换速度,如果是游戏或动画 它也可以研究、测量、验证系统的其他特征,比如可扩展性、可靠性和资源使用率。 二、 性能测试的关键指标 客户端性能的关键指标有: CPU占用率、内存占用率、流量耗用量、FPS(每秒传输帧数) (见下图)<img src="https://pic4.zhimg.com 它也可以研究、测量、验证系统的其他特征,比如可扩展性、可靠性和资源使用率。 二、 性能测试的关键指标 客户端性能的关键指标有: CPU占用率、内存占用率、流量耗用量、FPS(每秒传输帧数) (见下图)<img src="https://pic4.zhimg.com

    8330

    震惊!耗时还能这么优化??

    3.3.1 cpu使用率优化     我们先分析下普通模式下的CPU使用率,分析方式为通过profile转码过程中主要线程的方法耗时。 cpu使用率 测试用例:Duration: 00:01:02.66    1080x1920, bitrate:19926 kb/s   fps:60  输出信息:720x1280 bitrate:3500 kb/s fps:30 测试机型:Google Pixel 5     可以看到使用前后,cpu使用率可以完美归零,说明整体没有性能泄露的情况,其中转码过程中,cpu使用率稳定在18%左右,让我们详细分析下具体每个线程的使用情况 另外CPU耗时只能在一定程度上体现CPU使用率,渲染实际是在GPU执行,此时CPU出于等待状态,并不会造成很大损耗。     6.CPU使用率优化。 7.渲染流程优化,非编辑视频跳过中间渲染流程,优化Graphic内存和耗时。

    1.3K71

    ServerFrame::HashMap VS stl::unordered_map-性能探究之旅

    他们的插入效率、查找效率、空间使用率对比起来是分别是什么样的?也没有找到相关的测评,于是就自己动手,测试了一下,并对一些影响性能的地方修改、验证自己的猜想,最终得到一个比较好的hashmap的实践。 很快,就想到了他的 Hash 函数和冲突处理,决定从这里入手继续分析。 在好奇心驱使下,马上进行 3.1 用例的测试。 至于unordered_map,上图已经分析不出什么东西来,和HashMap比起来,它的变化缓慢了。 最长的链表达到了 5000以上,而且占比 有 0.705%,比我们期望的不冲突的占比还多了3倍。也就是说最差情况的比最好情况多了3倍。

    92200

    扫码关注腾讯云开发者

    领取腾讯云代金券