2 ポイント 投稿者 GN⁺ 2024-04-03 | 1件のコメント | WhatsAppで共有
  • AdobeでPhotoshop・Acrobatのような大規模アプリを複数環境へ移植する中で直面したクロスプラットフォーム移植の問題が、Renderlet開発の出発点となった
  • Renderletは、どこでも実行・埋め込み可能なWASMグラフィックフレームワークを目指し、アプリ開発のしやすさとGPU低レベル活用の両立を狙っている
  • 公開ランタイムのWanderはGPU上の低レベル3D APIを提供し、ここにRiveのオープンソース2Dベクターレンダラーを接続する実験が実装された
  • 現在はオープンアルファ直前の段階で、コンパイラとプラットフォーム統合の準備が整い次第、Show HNまたはLaunch HNを行う予定
  • Unityがゲームのクロスプラットフォーム開発を容易にしたように、Renderletはさまざまなビジュアルアプリケーションを複数環境で実行しやすくすることに焦点を当てている

Renderletが解決しようとしている移植性の問題

  • AdobeでPhotoshopやAcrobatのような大規模アプリケーションを、デスクトップ、Web、モバイル、クラウドで動作させることは大きな課題だった
    • LightroomとPhotoshopのWeb版は、JavaScript、Google PNaCl、asm.js、WebAssemblyを経由する長い道のりをたどった
    • 対象デバイスに合わせてGPUアーキテクチャを再検討する必要があり、シングルスレッドビルドやWeb ComponentsベースのUI再構成も必要だった
    • Webビルドは現在うまく動作しているが、その過程には10年にわたる作業が費やされた
  • グラフィックスタックは依然として移植性のボトルネックとして残っており、WebAssemblyはどこでも実行・埋め込み可能で、リアルタイムグラフィックスに必要な性能を出せる基盤として選ばれた
  • Renderletは、自己完結型のグラフィックモジュールを作って相互接続し、どのような環境上でも、どのようなアプリ内でも実行できる構造を重視している
  • 開発者はYCにソロ創業者として参加し、ここ6か月ほどRenderletを開発してきた

Rive Renderer統合実験

  • Riveが2Dベクターエンジンをオープンソース公開した後、RenderletのGPUバックエンドでRive Rendererを動かせるかを実験した
    • Rive RendererはSVGに似た高レベルの2D APIで構成されている
    • WanderはRenderletのオープンソースランタイム部分であり、GPU上に低レベルの3D APIを提供する
  • 実装の結果、RenderletのGPUバックエンドでRive Rendererライブラリを実行でき、3Dアプリでも2Dベクターバックエンドを使えるようになった
  • 動作例はVimeo動画で確認できる
  • 技術的な詳細はUsing renderlet with rive-rendererに整理されている
  • ランタイムWasm RendererであるWanderのコードはrenderlet/wanderで公開されている

1件のコメント

 
GN⁺ 2024-04-03
Hacker Newsの意見
  • PAL の段階を飛ばして、直接 SetupRuntime に進むほうがよい。グラフィックス非専門の開発者はこうした事項をよく知らず、API に不要な追加ステップを作るのは望ましくない。PAL は他では使われていないため、WebGPU を使うのがよい。(IPal は IRuntime のメンバーであるべきで、WebGPU コンテキストでは削除される準備ができている)。

    • WebGPU の使用を推奨: PAL 段階の省略、SetupRuntime からの直接開始、API 簡素化の必要性、IPal の IRuntime への統合と削除対象。
  • このプロジェクトは、クロスプラットフォーム GUI を作るための優れたウィジェットキットと、インタラクションモデルのための驚くべきキャンバスになり得る。C/C++ バックエンドと WASM ターゲットにより、ほぼあらゆる言語で FFI を構築できる。

    • クロスプラットフォーム GUI 開発の可能性: 多様な言語で FFI を構築可能、C/C++ バックエンドと WASM ターゲットの利点。
  • テキストとフォント対応の計画が気になる。一部のグラフィックエンジンは、望むあらゆる方法でテキストをサポートしているわけではない。OTF や WOFF2 ファイルを読み込み、任意の文字列を表示できるのかという質問。

    • テキストおよびフォント対応への質問: さまざまなテキスト表示方式への対応、OTF/WOFF2 ファイルの読み込みと文字列表示の可否。
  • このプロジェクトに大きな関心がある。ランタイム、イベントループ、FFI、ウィンドウポインタの所有権などについていくつか質問がある。オーディオプラグインと VST に関心があり、イベントループとウィンドウ管理には制約がある。JUCE は事実上の解決策だが、古くて使いづらい。

    • オーディオプラグインと VST への関心: ランタイム、イベントループ、FFI、ウィンドウ管理に関する質問、JUCE の代替としての可能性。
  • このプロジェクトは本当に素晴らしく、ここ数年ずっと夢見てきたものだ。WASM はグラフィックス/オーディオ/マルチメディア計算のためのポータブルな単位として大きな可能性を持っている。

    • WASM の可能性を強調: グラフィックス/オーディオ/マルチメディア計算のためのポータブルな単位としての WASM の可能性。
  • Godot Engine で WASM を動かすための作業を進めている。Safari における SharedArrayBuffer のアクセシビリティ問題や、オンラインゲームで重要な広告ネットワークへのアクセス問題をどのように克服したのか気になる。シングルスレッドと通常ビルドの問題も指摘している。

    • Godot Engine と WASM の取り組み: Safari の SharedArrayBuffer アクセシビリティ問題、広告ネットワークへのアクセス、シングルスレッドと通常ビルドの問題。
  • 3D グラフィックス/WASM 分野でさらに多くのプロジェクトを見られてうれしい。YC に入るためのコツがあるか質問している。Unreal Engine 5 を WebGPU と WebAssembly に移植する作業を何年も進めてきた。マルチスレッドレンダラーとアセットストリーミングシステムを備えており、ユーザーはゲーム/アプリ全体を事前にダウンロードする必要がない。また、アプリケーション全体を一度にメモリへ載せる必要もない。さらに、開発者がオンラインでプロジェクトを配布できる完全なホスティングプラットフォームとバックエンドも構築した。

    • Unreal Engine 5 の WebGPU および WebAssembly への移植: マルチスレッドレンダラー、アセットストリーミングシステム、ゲーム/アプリ全体のダウンロード不要、ホスティングプラットフォームとバックエンドの構築。
  • wasm I/O での発表は素晴らしく、この取り組みが注目を集めているのを見られてうれしい。

    • wasm I/O の発表への好意的な反応: 印象的な発表内容と、この取り組みへの注目。
  • Flutter の主要開発者である Ian Hickson の記事を読んだかと質問している。WASM を使って完全なクロスプラットフォーム UI フレームワークを実現できるという概念を説明しており、これは Flutter が採用している概念でもある。

    • Flutter と関連する WASM の利用: クロスプラットフォーム UI フレームワークの概念、Flutter との関連。
  • CAD カーネルについて、アプリに統合できる manifold を強く勧めている。

    • CAD カーネルの推薦: アプリ統合向けの manifold の推薦.