画像処理ライブラリ
1. 要件
JavaScriptから呼び出せる
WebAssemblyに圧倒的な高速化をもたらすことは期待していない
Reactから呼び出せる？
ここが自分でもよく分からない
普通、通常、コンポーネントはロジックを持たず、ロジックは hooks の中に分離される
React の中で使われるロジックはどのようなものが許容されるのか？
なんか自分の中にある偽の美意識が、複雑なロジックの呼び出しを許していない気がする 説明しよう！！
言説「useEffectは極力使うべきではない」
これはなぜ？
この言葉が語られたときのコンテキストを忘れている気がする
多分間違いではない
Reactコンポーネントを、一つの式と見立てたとき、副作用が存在することは、式の冪等性を殺してしまうことに等しい 冪等性のある副作用（？？？）があればいい？
なんじゃそりゃ
WebWorkerの呼び出し方法が分からない
個人的にもやもやしているのは、JavaScript以外のファイルのバンドルについてだと思う
CSSや画像を import したり、Comlinkのような抽象化が原因で、Reactの世界観にこれらをうまく取り込めていない 中身を読んでみたほうがいいぞ！！！そのほうが安全だぞ！！！！！
あれはなぜ動くのか？
あと、パスを指定したらそのJavaScriptファイルが使える仕組みもわからない。
HTMLでは、<script src > に書かれたファイルがGETされて、読み込まれると思う
読み込まれるって解像度低いなあ。どうなるの？
Chromeに限った話をする
Chromeは複数のプロセスで成り立っている
通信など、コアな部分はここに隠蔽されている
プロセスを分離することで、ブラウザのコアな実装をタブ側から隠蔽することができる
Rendererプロセスは次の構成で成り立っている
仮想マシン
V8エンジン
Blink
DOMツリー
BlinkはDOMツリーの描画を行う。
V8エンジンではJavaScriptが動作し、DOM APIを介してDOMツリーオブジェクトに変更を加えたり、読み取ったりできる
ここから考えて、<script>タグが描画されるとき、その中身をBlinkが読んで、V8エンジンにそれを実行させるという実装になっていると思う。
V8エンジンはJavaScriptを動かす環境としての役割しかないから、文法的に正しいJavaScriptであれば、そのスクリプトの発生源には興味がない
だから、V8エンジンに<script>の中身を渡せばBlink側の仕事は終わりだ
<script src>の場合、GETが完了したらやることは同じ。V8エンジンにJavaScriptを渡すだけ。
自分の中のReactの世界観にあるのは、JS/TSで書かれたコンポーネントと、例で見るような簡単なフックだけで、何百行というロジックを書くことをしてこなかった
どこに入れるのが正解なの？
WebAssemblyの呼び出し方がわからない
機能の仕組みを実例付きで説明できるようになろう・・・・。
必要な機能
動画
フレーム画像生成
2. 分析
次の種類がある
Canvasに描画する
描画しない
描画しない場合どういうふうにデータは渡されるのか？
今後調べること
動画処理の最適化方法
どのように動画を読み込み、圧縮させるのか
そもそも動画編集アプリで次のスタイルを取るのは一般的なのか？
1. 動画を取得
2. バイト列でメモリ上に持つ
動画情報を全部メモリに乗せる実装は正しいの？
特定ビットの読み取りは高速だろうけど、メモリ不足になる気がする
正しくないのなら、普通どう実装されるの？
現在フレームに近いフレームを一括で読み込んで、不要になったらメモリから破棄する？
部分的に読み込める仕組みが必要
3. 特定フレームにおけるフレーム画像を生成
動画編集アプリでは、フレーム画像を都度生成する？
効率的な方法はなんだろう
でもプレビューするにあたって、こうなるのは仕方ないか
4. 他エンティティと画像を合成
ここも分からない
Aviutlの実装では、フレームバッファが存在し、それに透過されたレイヤー画像を書き込んでく形を取っている これなら、各レイヤーをcanvasと見立てて、そこに書き込むという方法でも代替可能だよね 画像処理ライブラリで、各エンティティのフレーム画像（透過済）を順番に書き込むことでも可能
5. 書き出す際は、全フレーム画像を生成して連番画像として圧縮させる。
これは正しいの？
プレビュー画面でフレーム画像を生成するのは当然だけど、書き出しには別の方法を使ったりする？
各フレームは非同期に生成できるの？
できるとしたら、マルチスレッドで複数フレーム同時に生成したほうが速いね