Images et photos · Convertisseur et compresseur d'images
Comment Web Workers et OffscreenCanvas maintiennent la réactivité de la conversion d'image
· Comment ça marche
traitement du navigateur toile web-workers
L'encodage d'une grande image prend du temps CPU réel, et le faire sur le thread principal gèlerait la page. Cet article explique comment Web Workers et OffscreenCanvas déplacent ce travail hors du fil de l'interface utilisateur et ce que cette architecture signifie pour la confidentialité et les limites.
L'onglet qui se bloquerait - que se passe-t-il lorsqu'un encodage lourd s'exécute sur le fil qui dessine également la page
Le décodage, le redessinage et l'encodage d'un lot nécessitent un travail CPU et une mémoire de pixels décodée. Si chaque opération s'exécutait dans la même boucle d'événements qui gère les contrôles, les mises à jour de progression et la peinture, l'interface pourrait cesser de répondre jusqu'à ce qu'un fichier soit terminé. Le panneau ciblé crée donc paresseusement un module de travail lorsque la première conversion commence plutôt que de payer ce coût de démarrage pour un visiteur qui ne convertit jamais.
La réactivité est un objectif architectural, pas un timing promis. La charge de l'appareil, les dimensions de l'image, la mise en œuvre du navigateur et la composition des lots déterminent toujours la fluidité de la page. Vérifiez avec des fichiers représentatifs sur les appareils importants ; ne publiez pas de durée de conversion universelle et ne prétendez pas qu’un travailleur rend gratuitement un travail coûteux.
Le fil principal et pourquoi il est précieux : un fil pour la mise en page, la saisie et les scripts, et la durée pendant laquelle les tâches bloquent les trois
Le thread principal possède le DOM et les contrôles qu'un visiteur touche. ToolAcre l'utilise pour valider les sélections, décoder brièvement les dimensions source, construire les paramètres, l'état du rendu et télécharger les résultats. La boucle répétée de décodage, de dessin du canevas et d'encodage du lot se trouve derrière `image.worker.js`, permettant aux messages de progression de revenir entre les fichiers.
Un travailleur n'élimine pas toutes les tâches du fil principal. Chaque fichier sélectionné est initialement vérifié et mesuré dans le panneau, et les résultats y sont ensuite transformés en aperçus et en actions de téléchargement. La conception éloigne le pipeline lourd et répété de la propriété de l'interface tout en conservant les API et la présentation du navigateur dans le contexte auquel chacune appartient.
Web Workers : un deuxième thread sans DOM – ce qu'un travailleur peut et ne peut pas toucher, et comment les fichiers y parviennent
Le travailleur n'a pas d'accès DOM ordinaire. Il reçoit des descriptions d'éléments sérialisables, des paramètres et l'ArrayBuffer de chaque fichier. Pour chaque élément, il construit le même plan de conversion pur utilisé par l'interface, crée un Blob, exécute le décodage-dessin-encodage, convertit le Blob résultant en octets et enregistre un échec par fichier sans abandonner le reste du lot.
Cet isolement façonne également la gestion des erreurs. Un fichier corrompu peut entrer dans le tableau des échecs alors que les éléments ultérieurs continuent. Le travailleur vérifie l'annulation entre les éléments et signale la progression avec le nom de fichier actuel. L'interface utilisateur traduit le délai d'attente du travailleur en conseils pour essayer des images moins nombreuses ou plus petites plutôt que de laisser un bouton désactivé sans explication.
OffscreenCanvas : dessin et encodage sans élément visible – comment un travailleur obtient son propre canevas et appelle convertToBlob
`createCanvas` préfère `OffscreenCanvas` lorsque le constructeur existe. À l'intérieur de ce chemin, `encodeCanvas` appelle `convertToBlob` avec le type MIME cible et la qualité facultative. Le même moteur de rendu peut également créer un canevas HTML et utiliser `toBlob` basé sur le rappel, préservant ainsi une solution de secours pour les contextes dans lesquels OffscreenCanvas n'est pas disponible.
Il est important de décrire la solution de secours avec précision. OffscreenCanvas est préféré, ce n'est pas le seul canevas possible dans la source. De même, l'encodage WebP du navigateur est vérifié par le résultat d'encodage éventuel plutôt que supposé par la prise en charge du décodage. L'application promet une erreur lorsque l'encodeur demandé ne peut pas produire le format, pas de substitution silencieuse avec un autre type MIME.
Transférables et copies : déplacer un ImageBitmap ou un ArrayBuffer vers un travailleur sans dupliquer des dizaines de mégaoctets
Avant d'appeler le travailleur, le panneau lit chaque fichier dans un ArrayBuffer et inclut ces tampons dans la liste de transfert. La propriété est transférée au travailleur au lieu de cloner chaque tampon d'entrée. Après le codage, le travailleur encapsule les octets Blob dans un Uint8Array et enregistre ce tampon de sauvegarde pour le transfert sur le chemin de réponse.
Cela réduit les copies évitables, mais les images et les toiles décodées occupent toujours de la mémoire. `executePlan` ferme chaque ImageBitmap dans un bloc `finally` afin que ses pixels décodés puissent être libérés rapidement. Les transférables, le nettoyage explicite des bitmaps et la protection du budget des pixels répondent à différentes sources de pression ; aucun n'autorise une réclamation de lots illimitée.
Pourquoi cette architecture est également une question de confidentialité : l'ensemble du pipeline réside dans votre onglet et le panneau réseau reste silencieux
Le code de conversion appelle les API d'image et de canevas du navigateur sans demande de téléchargement de fichier. Un test unitaire protège la planification de chaque combinaison d'entrée-sortie prise en charge avec un accès au réseau interdit. La déclaration de confidentialité de la configuration est par conséquent étroite : le code de l’outil ne fait aucune requête transportant le fichier, le texte collé ou la sortie générée.
La page elle-même peut toujours charger les ressources du site et les scripts externes divulgués, le « panneau réseau silencieux » doit donc être interprété. Effacez DevTools après le chargement et recherchez un nom de fichier de test inoffensif distinctif ou des octets de charge utile dans les nouvelles requêtes. L'examen des sources et l'observation de l'exécution soutiennent ensemble une affirmation sur le chemin de conversion ; ni l’un ni l’autre ne transforme l’ensemble de l’environnement du navigateur en un bac à sable hors ligne.
D'où viennent les limites : les limites de mémoire et de toile remplacent les limites de téléchargement, le plafond est donc votre appareil
Le traitement local remplace une limite de téléchargement par des contraintes liées à la validation des entrées, aux pixels décodés, à l'allocation du canevas et à la mémoire disponible de l'appareil. Chaque fichier d'entrée est plafonné à 40 MB par le panneau ciblé. La géométrie de sortie prévue est adaptée à un budget de pixels de l'appareil, et l'utilisateur reçoit un avertissement indiquant les dimensions réduites lorsque ce garde modifie la demande.
Il n'y a pas de nombre de lots fixe dans la configuration. Vingt petits graphiques et vingt photos haute résolution ne sont pas des allocations équivalentes. Un téléphone peut tomber en panne plus tôt qu'un ordinateur de bureau. Le véritable conseil opérationnel est de traiter moins de fichiers ou de fichiers plus petits après un délai d'attente ou une panne de mémoire, et de ne pas publier un nombre maximum ou un plafond de mégapixels non pris en charge.
À retenir : interface lourde et silencieuse – comment Image Converter & Compressor effectue des conversions à partir du thread principal de votre appareil
L'interface reste plus silencieuse car le pipeline répété s'exécute dans un travailleur, son canevas peut être hors écran et les tampons d'octets volumineux voyagent en tant que transférables. Ce sont des propriétés de source concrètes, et non des raccourcis marketing. Ils expliquent où se déroule le travail et comment la progression revient sans prétendre que chaque navigateur la planifie de la même manière.
Testez l'architecture avec les images que votre flux de travail utilise réellement. Surveillez les contrôles pendant la conversion, confirmez la progression par fichier, inspectez les échecs et vérifiez le panneau Réseau pour le marqueur de test. La conception de ToolAcre vous donne des preuves observables : un véritable module de travail, des sorties mesurées et des octets de téléchargement locaux plutôt qu'une tâche distante opaque.