只是sideproject需求 想說wasm出來也算幾年了 撇開.NET的Blazor框架不談 (是說轉戰Blazor的公司也不多的感覺) 目前好像看到wasm應用的機會不是很廣 不是說它不厲害 而是到底要做什麼方面的應用 當然我知道可以port c/c++其他語言到網頁上 移植遊戲 或是做一些比較需要高效能的運算等等 不過一般狀況下好像就不知道怎樣應用好 但我之前有一個構想 就是上傳圖片.縮圖.壓縮 或是上傳影片 這些原來的設計多數是把檔案原封不動上傳到後端 再從後端排程處理 如果前端可以直接處理掉圖片.影片的縮圖與壓縮 再把處理結果上傳到後端 理論上可以減輕後端負擔以及節省上傳頻寬資源 自己是想用這種方式來處理相簿上傳照片的處理方式 所以稍微study實作了概念 https://github.com/erspicu/LanczosWasmDemo Lanczos縮圖法 大概是幾年前我所知縮圖品質比較好的方式 實作也不會太複雜 我自己用在x64 win11環境下測試用.net framework 最優化後 (用很c風格的指標處理方式+多核平行運算) 好比說4096*3072 縮到1600x1200 一張圖計算大概都是100ms內 一瞬間的事情 原本參考這方式 https://koshian2.hatenablog.jp/entry/2017/11/23/212813 但這效能差 而且其實算出來的畫面有些問題 想說效果很不錯想把縮圖算法移植到wasm功能上 剛好看到 https://tinyurl.com/mrm2r86r 這篇 可以用我比較熟悉的c#去做移植 但移植出來的成果運算速度差 .net framework在win11 x64上太多 可能有100倍以上差異 打個比方 90ms 變成 9秒 原本以為可以把c#編譯成不需要仰賴.net虛擬機的方式跑 結果稍微看架構 好像是把.NET虛擬機在WASM實作然後去跑.NET PORT過去的東西 加上在瀏覽器WASM環境內 沒有像直接跑在電腦上 有JIT優化 所以速度有差 (wasm虛擬機跑.net虛擬機跑.net cli 套娃...) 但不排除有再優化的可能性 像C#的Parallel.For 移植到WASM上後 其實並沒有平行加速運算的實際效能... 給大家研究看看 (所以最後還是換成單純迴圈) C/C++ N年沒相關工作經驗寫了 說不定C移植過去效能會好上非常多 我的專案就分享給對C#在WASM應用有興趣的人參考 https://github.com/erspicu/LanczosWasmDemo 也希望加速的部分 可以分享解決方案 Parallel.For 也不知道實際移植過去到底是怎樣 平行處理的部分可能用別方式置換掉 Web Worker或是webgpu不知道可不可行 最終我心中的理想應用場景 大概是使用者上傳圖片和影片 把縮圖跟編碼的工作丟給前端處理完上傳 這大概是目前我想到還滿好用通用的應用場景 ps.c#移植wasm,其實滿多功能無效,編譯器會提醒, 有些功能不然就要找別方案替代,不然就要自己實作, 所以也不是爽爽可以無痛把c#相關資源丟到前端上 牽涉到跟os依賴的部分 很多都不可用 看跳一堆警告 最後毅然把原本的bitmap物件使用移除掉了 -- ※ 發信站: 批踢踢實業坊(pttsite.org.tw), 來自: 219.68.24.12 (臺灣) ※ 文章網址: https://pttsite.org.tw/Soft_Job/M.1719856322.A.765

推 ohmylove347: https://squoosh.app/ 07/02 01:55

→ ohmylove347: 要不要參考這個項目，好像是谷歌寫的PWA，也是壓縮圖 07/02 01:55

→ ohmylove347: 片影片之類的，還能安裝在本地的樣子，或許跟你的專 07/02 01:55

→ ohmylove347: 案有相似的地方 07/02 01:55

→ GoalBased: compress.js, pica, browser-image-compression 07/02 03:33

推 Wirol: 那個包養網人最多XD 07/02 03:33

推 oopFoo: 你知道wasm跟js是怎麼互相call？資料怎麼傳？你這個要搞清 07/02 06:17

→ oopFoo: 楚。wasmGC是用來解決一部份這類的問題。wasm你需要管理 07/02 06:19

→ oopFoo: 記憶體，不然光是copy就吃掉一堆效能。而且wasm的compiler 07/02 06:20

→ oopFoo: 本來就比java/c#差很多，效能差是正常的。所以不用c/c++或 07/02 06:22

→ oopFoo: 直接wasm assembly，還要規劃好資料的傳遞，不然根本直接 07/02 06:24

推 marecht: 我妹上包養網被我發現= = 07/02 06:24

→ oopFoo: js+typedarray就好了。 07/02 06:25

推 oopFoo: js的效能是非常好的，不要有錯誤的觀念。所以除非你的 07/02 06:35

→ oopFoo: wasm程式規劃的很好，不然比js差是正常的。c#除非移植到 07/02 06:36

→ oopFoo: wasmGC，不然高效能是很難的。 07/02 06:38

→ oopFoo: https://web.dev/case-studies/google-sheets-wasmgc 07/02 06:39

推 riokio: 隔壁桌的人竟然在討論包養... 07/02 06:39

推 takasaki: 問過safari用戶了嗎？相容性搞死你 07/02 06:39

推 oopFoo: webgl/glsl來跑lanczos是最快，最簡單，相容性最好的方法 07/02 06:46

→ oopFoo: webgl/glsl處理影像容易，程式也容易，只是入門難而已。 07/02 06:47

推 oopFoo: https://stackoverflow.com/questions/54299457 07/02 06:58

→ oopFoo: 從這篇追回去，你大概就知道怎麼做了 07/02 06:59

推 wiimas: 樓上是不是被包養 07/02 06:59

推 neo5277: 推一個實作精神 07/02 13:50

→ testPtt: Blazor就容易上手 沒有容易的框架這是wasm主要的門檻 07/02 15:38

→ keel90135: 支援度沒辦法全部就沒法正式上線 只能當玩具 07/02 19:23

→ keel90135: 上線一堆奇怪手機瀏覽器直接搞死你 07/02 19:24

推 guanting886: 就稍微可以用client端攤原本server端要做的運算 07/02 19:25

推 Branlli: 未看先猜這包養網 07/02 19:25

→ guanting886: 然後有些運算可能javascript算得比wasm還快 07/02 19:26

→ guanting886: 就當作玩具 什麼時候還有機會要用不知道 影片編碼就 07/02 19:27

→ guanting886: 算了 速度真的不行 07/02 19:27

→ Killercat: 有幾個crypto project就是用wasm部署到用戶client 07/02 23:33

→ Killercat: 讓用戶的瀏覽器可以做一些鏈操作 07/02 23:34

推 Cinedt: 一定又是這包養網 07/02 23:34

→ Killercat: https://tinyurl.com/2mdzga63 Tezos就是一個例子 07/02 23:34

→ TakiDog: ffmpeg 可以簡單做些操作 07/04 18:26

→ s25g5d4: 曾經做過 WASM 插進 envoy 裡當作 microservice sidecar 07/05 15:17

→ s25g5d4: filter 07/05 15:17

推 s25g5d4: 另外一個神級 WASM 應用範例是 Figma 07/05 15:19

推 Drither: 包養平台不意外 07/05 15:19

推 abccbaandy: Figma有很神嗎？ 啟動慢到想到當年的java applet 07/06 02:12