アーキテクチャ

このセクションでは Delir の内部アーキテクチャ(と余談)について解説します。

Delir の構成

Delir は @delirvfx/core と呼ばれるエンジンとDelirと呼ばれるフロントエンドの2つに分かれています。
@delirvfx/core はプロジェクトスキーマの定義・ヘルパーの提供・レンダリングフローの制御と内部出力など「目に見えない領域」を担当。
Delirはそれらの機能を利用して、プロジェクトの編集機能・レンダリング結果の表示と出力の、「目に見える領域」を担当しています。

言語

@delirvfx/coreおよびDelirは開発言語として TypeScript を採用しており、一部のブートストラップスクリプトを除いてほぼ TypeScript で書かれています。

開発初期よりコードベースが大規模化することが予想され、自分以外が(あるいは数日後の自分が)触れないコードベースになるのは避けたかったため、この言語を選択しています。

なぜ JavaScript ランタイムを選んでしまったのか

  1. トライアンドエラーを高速に繰り返せる(Delir 自体の開発でも、プラグインの開発でも)
  2. コード量 対 利用可能機能が強い(少ないコストで複雑な機能を開発できる)
  3. 高度すぎて誰も保守できないアプリになるより、平易でオープンな技術を使うことでメンテナが入りやすくしたかった
    • そのために高速性は割りと犠牲にしている… ネイティブ系言語とガチでやりあえば間違いなくパフォーマンスは下になるだろうとは思っている。
  4. ネイティブ系のコード書きたくなかった

Delir を開発し始めたきっかけに、「AfterEffects でのピクセル操作の難しさ」というものがあります。

AfterEffects はエフェクトが豊富で高速に動き、機能や UI にも申し分のない素晴らしいアプリケーションですが、少し自分でエフェクトを書きたくなった時に「英語の PDF ドキュメント」と「C 言語(とその開発環境の整備)」の壁にぶつかります。気合で勉強すればよかったのかもしれませんが、少し画を加工したいがためにやるにはちょっとな〜と思いました。

そこから着想を得て Delir は KEN くん氏の「AviUtl」で実現されていたような「映像をスクリプトで直接加工する」という機能を AfterEffects のような UI の上で実現することを目標に開発が始まりました。

この要件に対し、JavaScript(というか Electron)は Canvas, WebGL, WebAudio, CSS, SVG, 動的コンパイル(vm module)など必要な技術が一通り揃っており、ネイティブ系言語でつまづきがちな問題(ライブラリのリンクとか、クロスプラットフォーム対応とか)をそこまで意識することなく、本当に作りたい部分に注力できる技術であると判断して採用されました。

ランタイム

@delirvfx/coreDelir ともにDOM APIが使える環境下で動くことを想定しています。
開発初期は Node.js ランタイム上で動作させることも視野に入れていましたが、以下の理由により目標から外されました。

  1. Delir が WebWorker や WebGL を利用するようになった場合、Node.js ではこれらの DOM API に依存する機能が使えない
  2. 代替のモジュールは存在するが、DOM API と代替モジュールの抽象化の必要性や互換性問題への考慮が必要
  3. それらを考慮する時間を割くより、新機能の開発や、体験の向上に時間を割きたい

  4. Node.js で出来ることは Electron で出来る(逆は違う)

  5. xvfb を使うことでオフスクリーンレンダリングできそうだしね