Bilder und Fotos · Bildkonverter und Kompressor
Wie Web Worker und OffscreenCanvas dafür sorgen, dass die Bildkonvertierung reaktionsfähig bleibt
· Wie es funktioniert
Browser-Verarbeitung Leinwand Web-Worker
Das Kodieren eines großen Bildes nimmt echte CPU-Zeit in Anspruch, und wenn es im Hauptthread ausgeführt würde, würde die Seite einfrieren. In diesem Beitrag wird erklärt, wie Web Worker und OffscreenCanvas diese Arbeit aus dem UI-Thread verschieben und was diese Architektur für den Datenschutz und für Einschränkungen bedeutet.
Der Tab, der einfrieren würde – was passiert, wenn eine starke Codierung auf dem Thread ausgeführt wird, der auch die Seite zeichnet?
Das Dekodieren, Neuzeichnen und Kodieren eines Stapels erfordert CPU-Arbeit und dekodierten Pixelspeicher. Wenn jeder Vorgang in derselben Ereignisschleife ausgeführt würde, die Steuerelemente, Fortschrittsaktualisierungen und das Malen verarbeitet, reagiert die Schnittstelle möglicherweise nicht mehr, bis eine Datei fertig ist. Das fokussierte Panel erstellt daher langsam einen Modularbeiter, wenn die erste Konvertierung beginnt, anstatt die Startkosten für einen Besucher zu zahlen, der nie konvertiert.
Reaktionsfähigkeit ist ein architektonisches Ziel, keine versprochene Zeitvorgabe. Geräteauslastung, Bildabmessungen, Browser-Implementierung und Batch-Zusammensetzung bestimmen immer noch, wie flüssig sich die Seite anfühlt. Überprüfen Sie anhand repräsentativer Dateien auf den wichtigen Geräten; Veröffentlichen Sie keine allgemeine Umstellungsdauer und behaupten Sie nicht, dass ein Arbeitnehmer teure Arbeit kostenlos erledigt.
Der Hauptthread und warum er wertvoll ist – ein Thread für Layout, Eingabe und Skripte und wie lange Aufgaben alle drei blockieren
Der Hauptthread besitzt das DOM und die Steuerelemente, die ein Besucher berührt. ToolAcre verwendet es, um Auswahlen zu validieren, kurz für Quellabmessungen, Build-Einstellungen, Renderstatus und Download-Ergebnisse zu dekodieren. Die wiederholte Decodierungs-, Canvas-Zeichnungs- und Codierungsschleife des Batches befindet sich hinter `image.worker.js` und ermöglicht die Rückgabe von Fortschrittsmeldungen zwischen Dateien.
Ein Worker eliminiert nicht jede Haupt-Thread-Aufgabe. Jede ausgewählte Datei wird zunächst im Panel überprüft und gemessen. Die Ergebnisse werden später dort in Vorschauen und Download-Aktionen umgewandelt. Das Design verlagert die wiederholt schwere Pipeline von der Schnittstelleneigenschaft weg, während Browser-APIs und Präsentation in dem Kontext bleiben, in den sie jeweils gehören.
Web Worker: ein zweiter Thread ohne DOM – was ein Worker anfassen kann und was nicht und wie Dateien dorthin gelangen
Der Worker hat keinen normalen DOM-Zugriff. Es empfängt serialisierbare Elementbeschreibungen, Einstellungen und den ArrayBuffer jeder Datei. Für jedes Element wird derselbe reine Konvertierungsplan erstellt, der von der Schnittstelle verwendet wird, ein Blob erstellt, Dekodieren-Zeichnen-Kodieren ausgeführt, das resultierende Blob in Bytes konvertiert und ein Fehler pro Datei aufgezeichnet, ohne den Rest des Stapels abzubrechen.
Diese Isolation prägt auch die Fehlerbehandlung. Eine beschädigte Datei kann in das Fehlerarray aufgenommen werden, während spätere Elemente weiterhin ausgeführt werden. Der Mitarbeiter prüft, ob zwischen Elementen Stornierungen vorliegen, und meldet den Fortschritt mit dem aktuellen Dateinamen. Die Benutzeroberfläche übersetzt eine Worker-Zeitüberschreitung in den Rat, weniger oder kleinere Bilder auszuprobieren, anstatt eine deaktivierte Schaltfläche ohne Erklärung zu belassen.
OffscreenCanvas: Zeichnen und Kodieren ohne sichtbares Element – wie ein Worker seine eigene Leinwand erhält und „convertToBlob“ aufruft
`createCanvas` bevorzugt `OffscreenCanvas`, wenn der Konstruktor vorhanden ist. Innerhalb dieses Pfads ruft `encodeCanvas` `convertToBlob` mit Ziel-MIME-Typ und optionaler Qualität auf. Derselbe Renderer kann auch einen HTML-Canvas erstellen und rückrufbasiertes `toBlob` verwenden, wodurch ein Fallback für Kontexte erhalten bleibt, in denen OffscreenCanvas nicht verfügbar ist.
Es ist wichtig, den Fallback genau zu beschreiben. OffscreenCanvas wird bevorzugt und nicht die einzig mögliche Leinwand in der Quelle. Ebenso wird die WebP-Codierung des Browsers anhand des endgültigen Codierungsergebnisses überprüft und nicht von der Decodierungsunterstützung angenommen. Die Anwendung verspricht einen Fehler, wenn der angeforderte Encoder das Format nicht erzeugen kann, und keine stille Ersetzung durch einen anderen MIME-Typ.
Übertragbare Dateien und Kopien – Verschieben einer ImageBitmap oder eines ArrayBuffers zu einem Worker, ohne Dutzende Megabyte zu duplizieren
Bevor der Worker aufgerufen wird, liest das Panel jede Datei in einen ArrayBuffer und nimmt diese Puffer in die Übertragungsliste auf. Das Eigentum geht auf den Worker über, anstatt jeden Eingabepuffer zu klonen. Nach der Codierung verpackt der Worker die Blob-Bytes in ein Uint8Array und registriert diesen Sicherungspuffer für die Übertragung auf dem Antwortpfad.
Dies reduziert vermeidbares Kopieren, dekodierte Bilder und Leinwände belegen jedoch weiterhin Speicher. `executePlan` schließt jede ImageBitmap in einem `finally`-Block, damit ihre dekodierten Pixel umgehend freigegeben werden können. Übertragbare Elemente, explizite Bitmap-Bereinigung und ein Pixel-Budget-Schutz bekämpfen verschiedene Druckquellen; keine berechtigt zu einem unbegrenzten Chargenanspruch.
Warum diese Architektur auch die Datenschutzgeschichte ist – die gesamte Pipeline befindet sich in Ihrem Tab und das Netzwerkpanel bleibt stumm
Der Konvertierungscode ruft Browser-Bild- und Canvas-APIs ohne eine Datei-Upload-Anfrage auf. Ein Unit-Test überwacht die Planung für jede unterstützte Eingabe-Ausgabe-Kombination mit verbotenem Netzwerkzugriff. Die Datenschutzerklärung der Konfiguration ist entsprechend eng gefasst: Der Tool-Code stellt keine Anfrage, die die Datei, den eingefügten Text oder die generierte Ausgabe enthält.
Die Seite selbst kann weiterhin Site-Assets und offengelegte externe Skripte laden, daher muss das „stille Netzwerkpanel“ interpretiert werden. Löschen Sie DevTools nach dem Laden und suchen Sie in neuen Anfragen nach einem eindeutigen, harmlosen Testdateinamen oder Nutzlastbytes. Quellenüberprüfung und Laufzeitbeobachtung stützen zusammen eine Aussage über den Konvertierungspfad; Weder verwandelt die gesamte Browserumgebung in eine Offline-Sandbox.
Woher die Grenzen kommen – Speicher- und Canvas-Obergrenzen ersetzen Upload-Obergrenzen, sodass die Obergrenze Ihr Gerät ist
Die lokale Verarbeitung ersetzt ein Upload-Limit durch Einschränkungen aus der Eingabevalidierung, den dekodierten Pixeln, der Canvas-Zuweisung und dem verfügbaren Gerätespeicher. Jede Eingabedatei wird vom fokussierten Bereich auf 40 MB begrenzt. Die geplante Ausgabegeometrie wird an das Pixelbudget eines Geräts angepasst und der Benutzer erhält eine Warnung mit der Angabe der reduzierten Abmessungen, wenn dieser Wächter die Anforderung ändert.
In der Konfiguration gibt es keine feste Batch-Anzahl. Zwanzig kleine Grafiken und zwanzig hochauflösende Fotos sind keine gleichwertigen Zuteilungen. Ein Telefon kann früher ausfallen als ein Desktop. Der ehrliche Betriebsratschlag besteht darin, nach einer Zeitüberschreitung oder einem Speicherausfall weniger oder kleinere Dateien zu verarbeiten und keine nicht unterstützte maximale Anzahl oder Megapixel-Obergrenze zu veröffentlichen.
Imbiss: Schwerer Arbeitsaufwand, leise Benutzeroberfläche – wie der Bildkonverter und -kompressor Konvertierungen außerhalb des Hauptthreads auf Ihrem Gerät durchführt
Die Schnittstelle bleibt leiser, da die wiederholte Pipeline in einem Worker ausgeführt wird, der Canvas außerhalb des Bildschirms liegen kann und große Bytepuffer als übertragbare Daten übertragen werden. Dabei handelt es sich um konkrete Quelleigenschaften, nicht um Marketing-Kurzformeln. Sie erklären, wo Arbeit stattfindet und wie der Fortschritt zurückkehrt, ohne zu behaupten, dass jeder Browser sie identisch plant.
Testen Sie die Architektur mit den Bildern, die Ihr Workflow tatsächlich verwendet. Beobachten Sie die Kontrollen während der Konvertierung, bestätigen Sie den Fortschritt pro Datei, überprüfen Sie Fehler und überprüfen Sie das Netzwerkfenster auf die Testmarkierung. Das Design von ToolAcre liefert Ihnen sichtbare Beweise: ein echtes Worker-Modul, gemessene Ausgaben und lokale Download-Bytes statt eines undurchsichtigen Remote-Jobs.