Adobeでの経験とRenderletの誕生
- AdobeでPhotoshopやAcrobatのような大規模アプリケーションのインフラに取り組んでいた。
- デスクトップ、Web、モバイル、クラウドで強力なコードベースを動かすことは大きな悩みの種だった。
- LightroomとPhotoshopをWebで動かすために、JavaScript、GoogleのPNaCl、asm.js、そして最終的にWebAssemblyへと至る複雑な道のりをたどった。
- GPUアーキテクチャを見直し、シングルスレッドビルドを動作させ、Webコンポーネントを中心にUIを再構成する必要があった。
- Webビルドは現在うまく動作しているが、ここに至るまでには10年という長い道のりがあった。
WebAssemblyの可能性
- グラフィックスタックは移植性における最大のボトルネックを生む部分である。
- ある日、WebAssembly（Wasm）がこの問題の解決策を提供すると気づいた。
- Wasmはどこでも実行でき、何にでも組み込めて、リアルタイムグラフィックスに十分な性能を提供する。
- そこで仕事を辞め、最初からWASMベースの移植可能かつ埋め込み可能なグラフィックフレームワークを作る冒険を始めた。
- アプリケーション開発者が簡単に望むグラフィックスを作れるよう、高水準でありながら、GPUを含む高性能アプリケーションに必要なあらゆるものを最大限活用できる低水準機能も提供する。
Renderletの紹介
- Renderletという名前は、埋め込み可能である点を強調するために付けられた。
- 独自のグラフィックモジュールを作って接続し、どんなものにも、どんな中でも簡単に相互運用できる。
- Unityが開発者にクロスプラットフォームゲームを簡単に作れるようにしたように、あらゆるビジュアルアプリケーションに対して同じことをしようという発想である。
開発過程とフィードバックのお願い
- YCにはソロ創業者として参加したが、この6か月の大半をこのプロジェクトの構築に集中して費やした。
- まだオープンアルファリリースの準備はできていないが、まもなく整う見込みで、これについて書き、見せ、フィードバックを得たいと考えている。
- これはアプリケーション開発者として夢見てきたものであり、他の人たちの考えを知りたいと思っている。
RiveとRenderletの組み合わせ
- Riveが2Dベクターエンジンをオープンソースとして公開し話題になったとき、興味を持った。
- RiveのレンダラーはSVGに似た高水準の2D APIで構築されており、RenderletのWanderレンダラーはGPU上に低水準の3D APIを公開する。
- RenderletはGPUバックエンドを使ってRive Rendererライブラリを実行でき、これによりすべての3Dアプリが2Dベクターバックエンドを持てる。
- 実際に実装して動作する様子はVimeoで見ることができ、GitHubでは技術的な内容をさらに深く掘り下げられる。
GN⁺の意見
- Renderletは、既存の複雑なグラフィックスアプリケーション移植の問題を解決しようとする革新的なアプローチを提示している。これは、開発者にさまざまなプラットフォームで一貫したユーザー体験を提供できる強力なツールになり得る。
- Renderletの開発者はAdobeでの経験を基に、実際の市場ニーズと技術的限界をよく理解しており、これはプロジェクトの成功可能性を高めている。
- しかし、Renderletはまだ初期段階にあり、オープンアルファリリースにも至っていないため、実環境での性能と安定性はまだ検証されていない。
- この技術が成功裏に導入されるには、広範なコミュニティ支援と開発者の積極的な参加が必要である。オープンソースプロジェクトとして、開発者の貢献とフィードバックがプロジェクトの成長に大きな影響を与えるだろう。
- Renderletと似た機能を提供する他のプロジェクトやフレームワークとしては、Unity、Unreal Engine、Godotなどがあるが、RenderletはWasmベースの軽量化と移植性により重点を置いた差別化されたアプローチを取っている。
1件のコメント
Hacker Newsの意見
PAL の段階を飛ばして、直接 SetupRuntime に進むほうがよい。グラフィックス非専門の開発者はこうした事項をよく知らず、API に不要な追加ステップを作るのは望ましくない。PAL は他では使われていないため、WebGPU を使うのがよい。（IPal は IRuntime のメンバーであるべきで、WebGPU コンテキストでは削除される準備ができている）。
このプロジェクトは、クロスプラットフォーム GUI を作るための優れたウィジェットキットと、インタラクションモデルのための驚くべきキャンバスになり得る。C/C++ バックエンドと WASM ターゲットにより、ほぼあらゆる言語で FFI を構築できる。
テキストとフォント対応の計画が気になる。一部のグラフィックエンジンは、望むあらゆる方法でテキストをサポートしているわけではない。OTF や WOFF2 ファイルを読み込み、任意の文字列を表示できるのかという質問。
このプロジェクトに大きな関心がある。ランタイム、イベントループ、FFI、ウィンドウポインタの所有権などについていくつか質問がある。オーディオプラグインと VST に関心があり、イベントループとウィンドウ管理には制約がある。JUCE は事実上の解決策だが、古くて使いづらい。
このプロジェクトは本当に素晴らしく、ここ数年ずっと夢見てきたものだ。WASM はグラフィックス／オーディオ／マルチメディア計算のためのポータブルな単位として大きな可能性を持っている。
Godot Engine で WASM を動かすための作業を進めている。Safari における SharedArrayBuffer のアクセシビリティ問題や、オンラインゲームで重要な広告ネットワークへのアクセス問題をどのように克服したのか気になる。シングルスレッドと通常ビルドの問題も指摘している。
3D グラフィックス／WASM 分野でさらに多くのプロジェクトを見られてうれしい。YC に入るためのコツがあるか質問している。Unreal Engine 5 を WebGPU と WebAssembly に移植する作業を何年も進めてきた。マルチスレッドレンダラーとアセットストリーミングシステムを備えており、ユーザーはゲーム／アプリ全体を事前にダウンロードする必要がない。また、アプリケーション全体を一度にメモリへ載せる必要もない。さらに、開発者がオンラインでプロジェクトを配布できる完全なホスティングプラットフォームとバックエンドも構築した。
wasm I/O での発表は素晴らしく、この取り組みが注目を集めているのを見られてうれしい。
Flutter の主要開発者である Ian Hickson の記事を読んだかと質問している。WASM を使って完全なクロスプラットフォーム UI フレームワークを実現できるという概念を説明しており、これは Flutter が採用している概念でもある。
CAD カーネルについて、アプリに統合できる manifold を強く勧めている。