首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  程序员

这样的想法可行不?

  •  
  •   VDimos · 56 天前 via Android · 2771 次点击
    这是一个创建于 56 天前的主题,其中的信息可能已经有所发展或是发生改变。

    webassembly 的性能现在已经很突出了,按照目前的发展趋势,wasm 的性能会逐渐逼近原生。

    如果用 web canvas 做绘图层,用 wasm 做计算。在 wasm 返回给 web 的 buffer 里只有像素信息,它已经做好了布局之类的。

    这样 canvas 只做绘图,而把计算交给了 wasm。或者说大部分情况下都是用的 canvas,相当于 canvas 成了最基本的组件。

    如果 canvas 再使用 webgl 来绘图,性能会不会更好一点儿?

    这样是不是更容易实现跨平台?

    但我不确定,这样的话性能会如何?各位有没有这方面的研究?一起探讨下

    29 回复  |  直到 2019-08-24 17:46:33 +08:00
        1
    kamilic   56 天前
    flutter?
        2
    VDimos   56 天前 via Android
    @kamilic flutter 原理不了解,不是直接编译两套代码吗?用 wasm 的话可以忽略掉平台差异
        3
    userdhf   56 天前
    想法挺好,是不是以后网页直接贴张设计稿上去,监听点击位置就好了...
        4
    nicoljiang   56 天前
    感兴趣,静候大佬作答。
        5
    love   56 天前
    然后不断加功能,再实现一遍 DOM
        6
    VDimos   56 天前 via Android
    @love 没必要实现 dom 那么复杂的标准,如果只实现基本的功能呢?我记得国外是有全部用 canvas 实现的应用?
        7
    murmur   56 天前
    可以,没必要,以前 react 就有 canvas 实现的版本,后面还是用了 react native
        8
    tabris17   56 天前
    即便 canvas 渲染能力出众,wasm 性能贴近原生,但是真的能保证用 canvas 实现一套 ui 组件的性能可以接近原生 html 吗?
        9
    augustheart   56 天前
    估摸了一下,可能要分你最终做的是什么东西吧。不过性能更好这个基本上不可能。
    这东西就好比客户端的 duilib,会省去一些系统组件间的交互,某些方面可能会快一点,但是要综合起来谈性能更好,同样的渲染条件下没可能。
        10
    Cooky   56 天前 via Android
    qt webgl 那个?
        11
    momocraft   56 天前
    字体,排版,样式,每一个都是无底深坑
        12
    loginbygoogle   56 天前 via Android
    不说性能问题,就一个简单的输入框控件就够你折腾
        13
    VDimos   56 天前 via Android
    @loginbygoogle 主要就是性能允许与否
        14
    VDimos   56 天前 via Android
    @momocraft 那如果光探讨可行性,可行吗?
        15
    gchxp   56 天前
    重复造了一个 js 游戏引擎?
        16
    momocraft   56 天前
    @VDimos 做来玩随便,有期待不可行
        17
    random0O   56 天前 via Android
    accessibility 也是个问题
        18
    VDimos   56 天前 via Android
    @gchxp 有点儿类似,但和游戏引擎的侧重点不太一样
        19
    sujin190   56 天前
    没多大用吧,用户层缓冲帧率上不去,不直接用 canvas 绘图,你显卡不是毛用没有了
    绘图渲染还是要用 canvas 直接完成,排版倒是可以用 wasm,感觉也比不了浏览器直接的体验更好吧
        20
    MMMMMMMMMMMMMMMM   56 天前
    可以,但是应用场景不会多

    因为现有的 web 无论是常规 site 还是 pwa,大部分瓶颈都不在性能上

    游戏可能用的上,但是人家游戏引擎就是专门做这个的,unity,ureal 貌似现在都能直接发布到 Webassembly 了

    强行 port 过去,重写一遍现有业务,npm 替代品没有的轮子再造一遍,你看大公司们乐意不

    个人自己玩玩倒蛮有意思的
        21
    exip   56 天前 via Android
    会不会出现把计算密集的实时性又不高的东西直接放到客户这边,类似 js 挖矿,只不过性能更高一点?
        22
    doublleft   56 天前
    @murmur
    @VDimos

    flipboard 之前就是用 canvas 来替代 DOM,现在还能找到一些文章。
    而且 做这个事的第一受益应该不是性能吧
        23
    secondwtq   56 天前 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   56 天前
    你只讨论了 UI 部分
    我们说跨平台,不止包括 UI 部分,还有
    界面交互——输入和输出,随数据动态
    硬件交互——照相 定位 声音 还有各类设备上的独有功能(比如电话短信等)
    如果这些都交给 WAS 来做,那么就是传统的 VM 模式了
    如果这些交给设备本身来做,那就是目前的跨平台模式:在各设备里面嵌入一个处理层(比如手机上的 js 引擎),剩下的交给原生。
        25
    areless   56 天前
    十多年前一个后端大佬看到我写前端,他说,你完全可以用 JS 生成并控制 DOM,这样更快。我还跟他争论前端讲究的是精简,class 或 id 用单字母就可以,能不使用 JS 就不使用,CSS 要兼容度 IE4.0 800 乘以 600 屏,2G 网络的 WAP 页要适配压缩中转后的一系列手机浏览器。
        26
    agagega   55 天前 via iPhone
    Flipboard 这样搞过。
    两年前也看过新闻,理论上 React 这种东西也可以输出到 DOM 以下的浏览器渲染层,不知道有没有下文。
        27
    GzhiYi   55 天前 via iPhone
    @areless 单个字母的 id 和 class 认真的吗?
        28
    wsxyeah   55 天前 via iPhone
    “用 wasm 做计算”具体是指计算啥?
        29
    starsriver   55 天前 via Android
    现在 js 也可以多线程计算,至于 canvas,我曾经想过这么干,后来放弃了。本来浏览器内核就干了这么一回事,你再浪费资源进行渲染,简直疯了。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1528 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 24ms · UTC 00:18 · PVG 08:18 · LAX 17:18 · JFK 20:18
    ♥ Do have faith in what you're doing.