1
F7TsdQL45E0jmoiG 242 天前
这...图啥啊
|
3
duiying 242 天前
搞个简单版本运营看看咯
|
4
tool2d 242 天前
emscripten 对很多库支持并不好,比如 curl 就不太好编译。
wasm 只适合中等偏小的软件,运行巨型商业软件够呛,代码估计要大改。 |
6
gam2046 242 天前
性能损耗应该是比较严重的,ffmpeg 是一个计算密集型的应用,wasm 版本的 ffmpeg 在转码方面,有时候只有 10%的速度。
|
7
tool2d 242 天前 1
@seanwhy 那你比较厉害,正常来说 curl 用的是标准 socket ,这在 wasm 浏览器里,都是不被支持的。
我以前遇到的最大问题,是内存管理方面。emscripten 粘合层,用了一种很奇怪的方法处理 fopen/fwrite ,文件大于 2 百兆就有问题,反正很折腾。 |
8
nieyujiang 242 天前 1
|
9
w4ngzhen 242 天前
“只能说客户端被浏览器蚕食的太厉害了” 还是没有 Get 到真正的原因,公司是希望以后这块的软件都通过浏览器作为媒介来使用,因为它随时可用,方便快捷,不用下客户端?但假设你真正编译为了 wasm ,大小并不比原生应用小。当然,我只是作为旁观者提出的疑问😂。
|
10
johnhsm2333 242 天前
我们这边做 Web 视频编辑器的,也是大量使用 wasm 场景,感觉这里问题提的挺好的。
|
11
johnhsm2333 242 天前
|
12
w4ngzhen 242 天前 1
另外对于产品设计方面,看到贵司的软件是 C++三维软件,我假设是一款生产力软件,作为用户,我用客户端在 PC 上使用,明显比在浏览器上使用更加放心😂。
|
13
johnhsm2333 242 天前
@johnhsm2333 #11
1. wasm 体积不能太大,会影响网页首屏时间,这个要压缩到 10 到 20m 左右,然后利用客户端缓存。所以不建议是所有功能都打包进来,只包括 js 或浏览器接口无法使用的功能会好一些。 2.确实有 3.验证挺麻烦的,我们也是限制了浏览器版本,比如 safari 无法访问,chrome 和 edge 特定版本以上之类的; 4.项目劣化会挺明显,而且前端同学不懂 wasm 的话,很难优化,所以我们已经把很多功能都使用 js 实现一遍了,这样效果最好。 |
14
icyalala 242 天前
对于通用计算来说,性能可以认为是降低到 1/3~1/5 ; simd/gpu 加速的部分性能下降就更多了,至少降一个量级。
|
15
cat 242 天前
你司的三维软件是不是卖不出去??搞这幺蛾子
|
16
horizon 242 天前
你 wasm 打包压缩了吗,压缩完还 100 多 M ?
|
17
mightybruce 242 天前
https://mp.weixin.qq.com/s/1XmH55nqs7wavsWJNT-tSw
B 站 有 ffmpeg 编译成 wasm 的案例, 并有相关 git 地址 |
18
mightybruce 242 天前
wasm 其实是非常有用的, 服务器计算挪动到客户端计算,大大减轻了服务端的压力和资源消耗。
|
19
thinkershare 242 天前
基本要大改,完全重写。
|
20
seanwhy OP @gam2046 那一般情况呢,
@johnhsm2333 1.大小问题可以通过进度条规避,毕竟大型软件,对加载时间可以有一定的宽容; 4.软件设计基本无需外部前端参与,完全由内部 C++暴露接口供外部调用,前端只需要做界面美化和接口调用的事,可以理解为我们提供了一个二次开发的 sdk |
21
Beginner1 242 天前
我司跟 3D 上 web 和他们一样,目前感觉也还好。不过我们主要使用 vtk ,代码确实进行了大量整改,就速度来说其实还好。可能我们功能没有他们那么复杂。当然 Ai 这些只有上云了。
|
24
gam2046 242 天前
@seanwhy #20 一般情况下,纯计算能力,wasm 效率能到 native 的 50%都够呛。毕竟 wasm 还是一个虚拟机,还得交给浏览器解释执行。而且现阶段 wasm 对于 pthread 的支持还是有点磕磕绊绊,很多开源项目的 wasm ,我看他们的处理方式是直接改成单线程保平安。
|
25
tool2d 242 天前
@seanwhy "那么用 emsctipten 编译出来,是否就意味着无需验证,也能运行于浏览器?"
验证很简单,写个单元测试跑一下就行了。 把对 wasm 的内心期望减半,再减半,就比较符合浏览器里运行的真实情况。 |
26
kaiserzhang123 242 天前
内存 4GB 的原因是因为编译到 wasm32 位的操作,最大就支持 4gb 内存,想要突破就只能使用 wasm64 位
|
27
kaiserzhang123 242 天前
@nieyujiang 编译到 wasm64 位就没有 4gb 内存的限制
|
28
icyalala 242 天前
@seanwhy https://00f.net/2023/01/04/webassembly-benchmark-2023/ 这有个通用计算的测试接近你的资料,平均下降到 43%,但是这是最快的 wasm 实现的结果。实际浏览器可能会再慢一些。
https://ffmpegwasm.netlify.app/docs/performance/ 这有个 Chrome+ffmpeg.wasm 的性能测试,平均下降到 8%,差了一个量级。 |
29
guanzhangzhang 242 天前
大佬,xorg-x11-server 和 openresty 有静态编译姿势吗
|
30
Jirajine 242 天前
就算能跑,你觉得 serve 一个 100m 的 wasm 文件给浏览器合适吗?
能编译到 wasm 的代码,可以认为就是可以运行的。但代码可以运行,不代表代码链接/调用的 API 也被支持。所以代码可以重用,其他都得重写。 |
31
br_wang 242 天前
提到 wasm ,我也有个问题:一个使用了 wasm 的网页,如果被 iframe 嵌入到另一个网页,还能正常访问到 wasm 文件并顺利运行么?
|
32
rabbbit 242 天前
|
33
churchill 242 天前
emscripten 文档上大量篇幅是讲 porting 和 optimizing webgl, 可见坑不少,祝楼主好运
可能不是很恰当的例子,有些图形库说是支持 emscripten 编译,可是桌面上是调的 opengl4.6 ,用 emscripten 编译就使用 emscripten 自带的 gl 头文件了,如果你的 shader 不是针对 es 300 写的运行起来就挂了 |
35
image72 242 天前 1
我觉得你想把这些搬到浏览器运行之前,可以先考虑发几个版本的 electron 编译版试试水,能移植的移植,能改写的改写,再考虑浏览器。electron 也是完整浏览器,也能支持内置 wasm 以及原生
从底层原生一步跨到纯浏览器 wasm, 步子太大,容易扯到蛋 |
36
opengg 242 天前 via Android
成功的项目基本没有全程 wasm 的,线上大多数都是 web 界面加部分重逻辑重计算部分走 wasm 调用。
当然也有类似的尝试,但我还没见过 full wasm 的商业产品。 |
38
sunzhuo 242 天前
我建议用 threejs 重现桌面版的 api ,然后再考虑 wasm 移植一些 c 功能。
|
40
mahaoqu 242 天前
如果你引用的所有库都能直接源码级跨 Win/Linux 两个系统,那大概率直接用 emscripten 编译到 WebAssembly 是能用的。比如去年谷歌那边就说 SQLite 用浏览器的 OPFS 后端跑通了,但这样的库还是太少。
|
43
seanwhy OP @kaiserzhang123 大佬细说,编译时加上什么标识呢
|
44
seanwhy OP @guanzhangzhang 只要你的库有 configure 或者 cmake ,编出来应该不难啊
|
47
jimrok 241 天前
感觉你要改设计,全部搬进 wasm 会崩溃的。建议 web 的版本先做简单的尝试,剥离最主要的功能,极简设计,看看效果。很多计算是不是可以用后端服务实现,这样不需要移植到浏览器上。
|
49
jeesk 241 天前 via Android
wasm 很多实现,有点扯,比如网络请求转移成 fetch , 太恶心了, 拿证书都拿不到,
|
50
dode 240 天前
可以搞客户端,纯跑程序,客户端额外开一个 HTTP 服务,浏览器提供界面啊
|
51
money1991 224 天前
我司也是搞客户端办公软件的,我把上千万行 c++代码编译到 wasm 了,并且也跑起来了。这块你也可以参考下 photoshop 或 libreoffice 的 wasm 版本,代码量都是这个级别的。
1. 先说体积,编译完大约 100M 左右,用 br 最高级压缩完 20M 左右,这个大小其实以目前网速不算大,配合缓存基本也仅影响首次。 2. 首次初始化稍慢,出去下载的时间,chrome 还会把它编译到一个二进制缓存,后续启动会非常快。 3. 性能我个人感觉能接受,但我司项目不依赖 opengl ,不算是强计算密集型项目,感觉应该有原生 50%左右的性能。 目前项目没有在搞了。。。老板觉得可能时机还有点早,有点遗憾。 |