webassembly 的性能现在已经很突出了,按照目前的发展趋势,wasm 的性能会逐渐逼近原生。
如果用 web canvas 做绘图层,用 wasm 做计算。在 wasm 返回给 web 的 buffer 里只有像素信息,它已经做好了布局之类的。
这样 canvas 只做绘图,而把计算交给了 wasm。或者说大部分情况下都是用的 canvas,相当于 canvas 成了最基本的组件。
如果 canvas 再使用 webgl 来绘图,性能会不会更好一点儿?
这样是不是更容易实现跨平台?
但我不确定,这样的话性能会如何?各位有没有这方面的研究?一起探讨下
1
kamilic 2019-08-23 13:25:08 +08:00
flutter?
|
2
VDimos OP @kamilic flutter 原理不了解,不是直接编译两套代码吗?用 wasm 的话可以忽略掉平台差异
|
3
userdhf 2019-08-23 13:31:45 +08:00
想法挺好,是不是以后网页直接贴张设计稿上去,监听点击位置就好了...
|
4
nicoljiang 2019-08-23 13:31:49 +08:00
感兴趣,静候大佬作答。
|
5
love 2019-08-23 13:54:09 +08:00
然后不断加功能,再实现一遍 DOM
|
6
VDimos OP @love 没必要实现 dom 那么复杂的标准,如果只实现基本的功能呢?我记得国外是有全部用 canvas 实现的应用?
|
7
murmur 2019-08-23 14:00:07 +08:00
可以,没必要,以前 react 就有 canvas 实现的版本,后面还是用了 react native
|
8
tabris17 2019-08-23 14:03:05 +08:00
即便 canvas 渲染能力出众,wasm 性能贴近原生,但是真的能保证用 canvas 实现一套 ui 组件的性能可以接近原生 html 吗?
|
9
augustheart 2019-08-23 14:11:35 +08:00
估摸了一下,可能要分你最终做的是什么东西吧。不过性能更好这个基本上不可能。
这东西就好比客户端的 duilib,会省去一些系统组件间的交互,某些方面可能会快一点,但是要综合起来谈性能更好,同样的渲染条件下没可能。 |
10
Cooky 2019-08-23 14:17:30 +08:00 via Android
qt webgl 那个?
|
11
momocraft 2019-08-23 14:20:05 +08:00
字体,排版,样式,每一个都是无底深坑
|
12
loginbygoogle 2019-08-23 14:48:40 +08:00 via Android
不说性能问题,就一个简单的输入框控件就够你折腾
|
13
VDimos OP @loginbygoogle 主要就是性能允许与否
|
15
gchxp 2019-08-23 16:08:20 +08:00
重复造了一个 js 游戏引擎?
|
17
random0O 2019-08-23 16:35:05 +08:00 via Android
accessibility 也是个问题
|
19
sujin190 2019-08-23 17:12:14 +08:00
没多大用吧,用户层缓冲帧率上不去,不直接用 canvas 绘图,你显卡不是毛用没有了
绘图渲染还是要用 canvas 直接完成,排版倒是可以用 wasm,感觉也比不了浏览器直接的体验更好吧 |
20
MMMMMMMMMMMMMMMM 2019-08-23 17:13:02 +08:00
可以,但是应用场景不会多
因为现有的 web 无论是常规 site 还是 pwa,大部分瓶颈都不在性能上 游戏可能用的上,但是人家游戏引擎就是专门做这个的,unity,ureal 貌似现在都能直接发布到 Webassembly 了 强行 port 过去,重写一遍现有业务,npm 替代品没有的轮子再造一遍,你看大公司们乐意不 个人自己玩玩倒蛮有意思的 |
21
exip 2019-08-23 17:19:04 +08:00 via Android
会不会出现把计算密集的实时性又不高的东西直接放到客户这边,类似 js 挖矿,只不过性能更高一点?
|
22
doublleft 2019-08-23 17:44:41 +08:00
|
23
secondwtq 2019-08-23 21:15:14 +08:00 via iPad 2
我看 flipboard 那个文章的意思就是他主要是为了性能做的
这个问题我觉得可以换一个角度看 根据我的观察,UI 库(指广义的 UI 库,不是前端一亩三分地里面的那几个)按照其绘制界面的方式可以分为两个流派 一个是用更高(或不同)的抽象包装平台提供的 GUI 相关的 API 和控件,比如 Windows 平台的原生 API 是 Win32,微软就有 MFC、WinForms 等一堆库来做这个包装,Borland 的 VCL 应该也算(没记错的话应该是)。这种做的比较大的,跨平台的我就知道一个 wxWidget。还有 SwiftUI,按照 Apple 的说法( SwiftUI 使用了 UIKit/AppKit )。 SwiftUI 是属于这一类的,另外 UIKit 和 AppKit 的基本思路一样,但是确实是两套不同的 API,所以如果 SwiftUI 能实现一套代码在不同 Apple 平台上跑(这个我没了解过,我主要对框架设计思路感兴趣),那勉强也算个跨平台吧 ... 我们把这一种框架称为“老实人框架” 另一种就是我用平台原生的 API 帮我创建一个窗口,再让平台帮我在窗口里面搞一个 canvas (指代任意图形 API 的 context ),跑一个 event loop,然后就变身渣男把平台给踹飞了。窗口里面的控件则完全由 UI 库自己模拟出来。这种做的比较有名的,远有微软的 WPF ——虽然只能在一个平台上面跑,但是还是自己把 W in32 控件重新做了一遍 ... 然后到死都还有性能问题,近有 Flutter ( Flutter 用的应该是 Skia,Chrome 的 UI 应该也是这么画的,所以 Chrome 也 ...) 实际上 Qt、GTK、Swing、JavaFX 都是这种方式,几乎所有的游戏也是这种方式( Apple 甚至默认了游戏可以随便折腾不用管他那一套理论) 我们把这一种框架称为“渣男框架” 现在我们来证明“老实人框架”和“渣男框架”是可以无限互相嵌套的 ... 说到平台,这里的平台 API,在 Windows 指的是 Win32 那一套( CreateWindow 之类的),在 Mac/iOS 指的是 Cocoa/CocoaTouch,在 Android 指的是 ... 好吧就是 Android 那个 ... 我也不知道叫什么,可能谷歌起名部需要努把力了 Linux 不存在(至少是不存在唯一的)平台原生 GUI API,非要说的话 libX11 算一个?好吧这个还是以你用 X 为前提的 ... 这里有意思的是,如果你把 GTK 看成“ Linux 原生 API ”的话(毕竟 GTK 在其他平台使用的很少),那 GTK 就可以被归类为“老实人框架”了 ... 其实还是有一点区别的,因为这种情况下你就是在直接调原生 API,而没有在用额外的 UI 框架 ... 所以应该说是 gtkmm 属于“老实人框架” ... 不过 anyway,这里的启发是,Cocoa 和 Android 这些框架在 UI 方面的内部实现实际上可能和“渣男框架”区别并不大,只是人为原因(官方钦定硬点)把它放到了“平台原生”这一层里面 有了上面的思考,现在我们就把 Android API 本身当成一个“第三方 UI 框架”,然后你写了个 Flutter 程序跑在 Android 上面,这就相当于你在一个“渣男框架”里面嵌套了另一个“渣男框架” 你写了个 React Native 程序跑在 Android 上面,React Native 是创建 native 控件的,因此属于“老实人框架”,这个相当于你在“渣男框架”里面嵌套了一个“老实人框架” 回到楼主的问题,首先 Web 这个东西可以被认为是一个拙劣的“渣男框架” 这个和计算机中另外一个规律,“ Greenspun ’ 10th rule ” 是异曲同工的:“任何 C 或 Fortran 程序复杂到一定程度之后,都会包含一个临时开发的、只有一半功能的、不完全符合规格的、到处都是 bug 的、运行速度很慢的 Common Lisp 实现。” 做过前端应该明白为什么 Web 可以被称为“拙劣的‘渣男框架’” ... DOM+CSS 可以被看作是 Web Native API,从这个角度讲,Angular/React/Vue 这些可以被视为建构于 Web 之上的“老实人框架” 然后你在 Android 上面跑的 React Native 程序里面嵌套了一个 WebView,里面放了一个 React 应用,现在你在: 一个渣男框架里面 ( Android API ) 嵌套了一个老实人框架 ( React Native ) 里面又嵌套了一个渣男框架 ( Web ) 里面又嵌套了一个老实人框架 ( React ) 有没有一点 “ Java 应用调用栈”( https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack1.png )的意思? 楼主的意思就是,我能不能在一个“渣男框架”里面再嵌套一个“渣男框架”,理论上显然是可以的,你甚至可以继续嵌套 ... 至于实际有多大意义,那就是另一个话题了 |
24
janus77 2019-08-23 21:28:33 +08:00
你只讨论了 UI 部分
我们说跨平台,不止包括 UI 部分,还有 界面交互——输入和输出,随数据动态 硬件交互——照相 定位 声音 还有各类设备上的独有功能(比如电话短信等) 如果这些都交给 WAS 来做,那么就是传统的 VM 模式了 如果这些交给设备本身来做,那就是目前的跨平台模式:在各设备里面嵌入一个处理层(比如手机上的 js 引擎),剩下的交给原生。 |
25
areless 2019-08-23 21:58:51 +08:00
十多年前一个后端大佬看到我写前端,他说,你完全可以用 JS 生成并控制 DOM,这样更快。我还跟他争论前端讲究的是精简,class 或 id 用单字母就可以,能不使用 JS 就不使用,CSS 要兼容度 IE4.0 800 乘以 600 屏,2G 网络的 WAP 页要适配压缩中转后的一系列手机浏览器。
|
26
agagega 2019-08-24 09:03:42 +08:00 via iPhone
Flipboard 这样搞过。
两年前也看过新闻,理论上 React 这种东西也可以输出到 DOM 以下的浏览器渲染层,不知道有没有下文。 |
28
wsxyeah 2019-08-24 10:38:39 +08:00 via iPhone
“用 wasm 做计算”具体是指计算啥?
|
29
starsriver 2019-08-24 17:46:33 +08:00 via Android
现在 js 也可以多线程计算,至于 canvas,我曾经想过这么干,后来放弃了。本来浏览器内核就干了这么一回事,你再浪费资源进行渲染,简直疯了。
|