アーキテクチャ

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

Delirの構成

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

言語

delir-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)など必要な技術が一通り揃っており、ネイティブ系言語でつまづきがちな問題(ライブラリのリンクとか、クロスプラットフォーム対応とか)をそこまで意識することなく、本当に作りたい部分に注力できる技術であると判断して採用されました。
「どうしてJavaScriptでここまでしたんだ」という意見に対しては、「そこにDOM APIがあったから」と答えます。実装できちゃったから仕方がない。

ランタイム

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

  1. DelirがWebWorkerやWebGLを利用するようになった場合、Node.jsではこれらのDOM APIに依存する機能が使えない
  2. 代替のモジュールは存在するが、DOM APIと代替モジュールの抽象化の必要性や互換性問題への考慮が必要
  3. それらを考慮する時間を割くより、新機能の開発や、体験の向上に時間を割きたい
    • Node.jsで出来ることはElectronで出来る(逆は違う)
    • xvfbを使うことでオフスクリーンレンダリングできそうだしね

results matching ""

    No results matching ""