画像と写真 · 画像コンバーター & コンプレッサー
Web Workers と OffscreenCanvas が画像変換の応答性を維持する方法
· 仕組み
ブラウザ処理 キャンバス ウェブワーカー
大きな画像のエンコードには実際の CPU 時間がかかり、メインスレッドで実行するとページがフリーズします。この投稿では、UI スレッドから離れて動作する Web Workers と OffscreenCanvas がどのように移動するか、またそのアーキテクチャがプライバシーと制限にとって何を意味するのかについて説明します。
フリーズするタブ — ページの描画も行うスレッドで重いエンコードが実行されるとどうなるか
バッチのデコード、再描画、エンコードには、CPU の作業とデコードされたピクセル メモリが必要です。すべての操作が、コントロール、進行状況の更新、ペイントを処理する同じイベント ループで実行されると、ファイルが終了するまでインターフェイスが応答を停止する可能性があります。したがって、フォーカスされたパネルは、最初のコンバージョンが開始されるときに、コンバージョンに至らない訪問者に起動コストを支払うのではなく、遅延してモジュール ワーカーを作成します。
応答性はアーキテクチャ上の目標であり、約束されたタイミング数値ではありません。デバイスの負荷、画像のサイズ、ブラウザの実装、バッチ構成は、ページがどの程度滑らかに感じられるかを決定します。重要なデバイス上の代表的なファイルを使用して検証します。普遍的な変換期間を公開したり、労働者が高価な作業を無料にすると主張したりしないでください。
メイン スレッドとそれが貴重な理由 - レイアウト、入力、スクリプト用の 1 つのスレッド、およびタスクが 3 つすべてをブロックする時間
メインスレッドは、DOM と訪問者が触れるコントロールを所有します。 ToolAcre はこれを使用して、選択内容を検証し、ソース寸法を簡単にデコードし、設定を構築し、ステータスをレンダリングし、結果をダウンロードします。バッチの繰り返されるデコード、キャンバス描画、エンコード ループは `image.worker.js` の背後に存在し、ファイル間で進行状況メッセージを返すことができます。
ワーカーは、すべてのメインスレッド タスクを削除するわけではありません。選択された各ファイルは最初にパネルでチェックおよび測定され、結果は後でプレビューに変換され、そこでダウンロード アクションが行われます。この設計では、ブラウザ API とプレゼンテーションをそれぞれが属するコンテキストに保ちながら、繰り返される重いパイプラインをインターフェイスの所有権から遠ざけます。
Web ワーカー: DOM のない 2 番目のスレッド - ワーカーがアクセスできるものとできないもの、およびファイルがそこに移動する方法
ワーカーには通常の DOM アクセスがありません。シリアル化可能な項目の説明、設定、各ファイルの ArrayBuffer を受け取ります。すべての項目に対して、インターフェイスで使用されるのと同じ純粋な変換計画を構築し、Blob を作成し、デコード、描画、エンコードを実行し、結果の Blob をバイトに変換し、残りのバッチを破棄することなくファイルごとの失敗を記録します。
この分離により、エラー処理も形成されます。破損したファイルが失敗配列に入る可能性がありますが、その後の項目は続行されます。ワーカーはアイテム間のキャンセルをチェックし、現在のファイル名で進行状況を報告します。 UI は、ワーカーのタイムアウトを、無効になったボタンを何も説明せずにそのままにするのではなく、より少ない、またはより小さい画像を試すようアドバイスに変換します。
OffscreenCanvas: 表示要素を使用しない描画とエンコード — ワーカーが独自のキャンバスを取得し、convertToBlob を呼び出す方法
`createCanvas` は `OffscreenCanvas` を優先します。そのパス内で、`encodeCanvas` はターゲット MIME タイプとオプションの品質を指定して `convertToBlob` を呼び出します。同じレンダラーで HTML キャンバスを作成し、コールバック ベースの `toBlob` を使用して、OffscreenCanvas が使用できないコンテキストのフォールバックを保持することもできます。
フォールバックを正確に記述することが重要です。ソース内で使用できる唯一のキャンバスではなく、OffscreenCanvas が優先されます。同様に、ブラウザーの WebP エンコードは、デコード サポートから推測されるのではなく、最終的なエンコード結果によってチェックされます。要求されたエンコーダーがフォーマットを生成できない場合、アプリケーションは、別の MIME タイプへのサイレント置換ではなく、エラーを約束します。
転送可能ファイルとコピー — 数十メガバイトを複製せずに ImageBitmap または ArrayBuffer をワーカーに移動する
ワーカーを呼び出す前に、パネルは各ファイルを ArrayBuffer に読み取り、それらのバッファを転送リストに含めます。すべての入力バッファーを複製するのではなく、所有権がワーカーに移動します。エンコード後、ワーカーは Blob バイトを Uint8Array にラップし、そのバッキング バッファーを応答パスでの転送用に登録します。
これにより、回避可能なコピーが減りますが、デコードされたイメージとキャンバスは依然としてメモリを占有します。 `executePlan` は、`finally` ブロック内の各 ImageBitmap を閉じて、デコードされたピクセルを即座に解放できるようにします。転送可能ファイル、明示的なビットマップ クリーンアップ、およびピクセル バジェット ガードは、さまざまなプレッシャーの原因に対処します。 none は無制限のバッチ請求を許可します。
このアーキテクチャがプライバシーの問題でもある理由 — パイプライン全体がタブ内に存在し、ネットワーク パネルは沈黙したままになります
変換コードは、ファイルのアップロード リクエストを行わずに、ブラウザーの画像とキャンバスの API を呼び出します。単体テストは、ネットワーク アクセスが禁止されている、サポートされているすべての入出力の組み合わせの計画を保護します。それに応じて、構成のプライバシーに関する声明も限定的です。ツール コードは、ファイル、貼り付けられたテキスト、または生成された出力を運ぶリクエストを行いません。
ページ自体は引き続きサイト アセットと公開された外部スクリプトを読み込むことができるため、「サイレント ネットワーク パネル」を解釈する必要があります。ロード後に DevTools をクリアし、新しいリクエストで特徴的な無害なテスト ファイル名またはペイロード バイトを探します。ソース レビューと実行時の観察を組み合わせると、変換パスに関する主張が裏付けられます。どちらもブラウザ環境全体をオフラインのサンドボックスに変えるものではありません。
制限はどこから来るのか — アップロードの上限はメモリとキャンバスの上限に置き換わるため、上限はデバイスになります
ローカル処理は、アップロード制限を入力検証、デコードされたピクセル、キャンバス割り当て、および利用可能なデバイス メモリからの制約に置き換えます。各入力ファイルは、フォーカスされたパネルによって 40 MB に制限されます。計画された出力ジオメトリはデバイスのピクセル バジェットに適合し、ガードがリクエストを変更すると、ユーザーは縮小された寸法を示す警告を受け取ります。
構成には固定バッチ数はありません。 20 枚の小さなグラフィックと 20 枚の高解像度の写真は、同等の割り当てではありません。電話機はデスクトップよりも早く故障する可能性があります。運用に関する真実のアドバイスは、タイムアウトまたはメモリ障害の後に処理するファイルの数を減らすか、または小さくすることであり、サポートされていない最大数やメガピクセルの上限を公開しないことです。
要点: 重労働で静かなインターフェイス — 画像コンバーターと圧縮機がデバイスのメインスレッドから変換を実行する方法
ワーカー内でパイプラインが繰り返し実行され、そのキャンバスが画面外に表示され、大きなバイト バッファーが転送可能として移動されるため、インターフェイスは静かなままです。これらは具体的なソース プロパティであり、マーケティングの略語ではありません。これらは、すべてのブラウザーが同じようにスケジュールを設定するとは主張せずに、どこで作業が発生し、どのように進行状況が返されるかを説明しています。
ワークフローが実際に使用するイメージを使用してアーキテクチャをテストします。変換中のコントロールを監視し、ファイルごとの進行状況を確認し、失敗を検査し、ネットワーク パネルでテスト マーカーを確認します。 ToolAcre の設計は、不透明なリモート ジョブではなく、実際のワーカー モジュール、測定された出力、ローカル ダウンロード バイトなど、目に見える証拠を提供します。