Imagens e fotos · Conversor e compressor de imagens
Como Web Workers e OffscreenCanvas mantêm a conversão de imagens responsiva
· Como funciona
processamento do navegador tela trabalhadores da web
Codificar uma imagem grande leva tempo real CPU e fazê-lo no thread principal congelaria a página. Esta postagem explica como Web Workers e OffscreenCanvas movem esse trabalho para fora do thread de UI e o que essa arquitetura significa para privacidade e limites.
A guia que congelaria — o que acontece quando uma codificação pesada é executada no thread que também desenha a página
Decodificar, redesenhar e codificar um lote requer CPU trabalho e memória de pixels decodificados. Se cada operação fosse executada no mesmo loop de eventos que lida com controles, atualizações de progresso e pintura, a interface poderia parar de responder até que um arquivo fosse concluído. O painel focado, portanto, cria um módulo de trabalho preguiçosamente quando a primeira conversão começa, em vez de pagar o custo inicial para um visitante que nunca converte.
A capacidade de resposta é uma meta arquitetônica, não um número de tempo prometido. O carregamento do dispositivo, as dimensões da imagem, a implementação do navegador e a composição do lote ainda determinam a fluidez da página. Verifique com arquivos representativos dos dispositivos importantes; não publique uma duração de conversão universal nem afirme que um trabalhador faz trabalho caro gratuitamente.
O thread principal e por que ele é precioso — um thread para layout, entrada e scripts, e por quanto tempo as tarefas bloqueiam todos os três
O thread principal possui DOM e os controles que um visitante toca. ToolAcre o usa para validar seleções, decodificar brevemente dimensões de origem, configurações de construção, status de renderização e download de resultados. A decodificação repetida, o desenho da tela e o loop de codificação do lote ficam atrás de `image.worker.js`, permitindo que mensagens de progresso retornem entre os arquivos.
Um trabalhador não elimina todas as tarefas do thread principal. Cada arquivo selecionado é inicialmente verificado e medido no painel, e os resultados são posteriormente transformados em visualizações e ações de download. O design afasta o pipeline pesado e repetido da propriedade da interface, ao mesmo tempo que mantém as APIs e a apresentação do navegador no contexto ao qual cada uma pertence.
Web Workers: um segundo thread sem DOM — o que um trabalhador pode ou não tocar e como os arquivos chegam até ele
O trabalhador não tem acesso DOM comum. Ele recebe descrições de itens serializáveis, configurações e o ArrayBuffer de cada arquivo. Para cada item ele constrói o mesmo plano de conversão puro usado pela interface, cria um Blob, executa decode-draw-encode, converte o Blob resultante em bytes e registra uma falha por arquivo sem abandonar o resto do lote.
Esse isolamento também molda o tratamento de erros. Um arquivo corrompido pode entrar na matriz de falhas enquanto os itens posteriores continuam. O trabalhador verifica o cancelamento entre itens e relata o progresso com o nome do arquivo atual. A IU traduz o tempo limite do trabalhador em um conselho para tentar imagens menores ou menores, em vez de deixar um botão desativado sem explicação.
OffscreenCanvas: desenho e codificação sem um elemento visível — como um trabalhador obtém sua própria tela e chama convertToBlob
`createCanvas` prefere `OffscreenCanvas` quando o construtor existe. Dentro desse caminho, `encodeCanvas` chama `convertToBlob` com tipo de destino MIME e qualidade opcional. O mesmo renderizador também pode criar uma tela HTML e usar `toBlob` baseado em retorno de chamada, preservando um substituto para contextos onde OffscreenCanvas não está disponível.
É importante descrever o substituto com precisão. OffscreenCanvas é o preferido, não a única tela possível na origem. Da mesma forma, a codificação WebP do navegador é verificada pelo resultado da codificação eventual, em vez de assumida pelo suporte de decodificação. O aplicativo promete um erro quando o codificador solicitado não consegue produzir o formato, e não uma substituição silenciosa por outro tipo MIME.
Transferíveis e cópias — mover um ImageBitmap ou ArrayBuffer para um trabalhador sem duplicar dezenas de megabytes
Antes de chamar o trabalhador, o painel lê cada arquivo em um ArrayBuffer e inclui esses buffers na lista de transferência. A propriedade passa para o trabalhador em vez de clonar cada buffer de entrada. Após a codificação, o trabalhador agrupa os bytes Blob em um Uint8Array e registra esse buffer de apoio para transferência no caminho de resposta.
Isso reduz as cópias evitáveis, mas as imagens e telas decodificadas ainda ocupam memória. `executePlan` fecha cada ImageBitmap em um bloco `finally` para que seus pixels decodificados possam ser liberados imediatamente. Transferíveis, limpeza explícita de bitmap e proteção de orçamento de pixels abordam diferentes fontes de pressão; nenhum autoriza uma reivindicação de lote ilimitada.
Por que essa arquitetura também é a história da privacidade — todo o pipeline fica na sua guia e o painel da rede permanece silencioso
O código de conversão chama APIs de imagem e tela do navegador sem uma solicitação de upload de arquivo. Um teste de unidade protege o planejamento para cada combinação de entrada-saída suportada com acesso à rede proibido. A declaração de privacidade da configuração é correspondentemente restrita: o código da ferramenta não faz nenhuma solicitação para transportar o arquivo, o texto colado ou a saída gerada.
A própria página ainda pode carregar ativos do site e scripts externos divulgados, portanto, o “painel de rede silencioso” precisa de interpretação. Limpe o DevTools após o carregamento e procure um nome de arquivo de teste inofensivo distinto ou bytes de carga em novas solicitações. A revisão da fonte e a observação do tempo de execução juntas apoiam uma afirmação sobre o caminho de conversão; nenhum dos dois transforma todo o ambiente do navegador em uma sandbox offline.
De onde vêm os limites — os limites de memória e tela substituem os limites de upload, então o teto é o seu dispositivo
O processamento local substitui um limite de upload por restrições de validação de entrada, pixels decodificados, alocação de tela e memória disponível do dispositivo. Cada arquivo de entrada é limitado a 40 MB pelo painel em foco. A geometria de saída planejada é ajustada a um orçamento de pixels do dispositivo e o usuário recebe um aviso nomeando as dimensões reduzidas quando o guarda altera a solicitação.
Não há contagem fixa de lotes na configuração. Vinte pequenos gráficos e vinte fotos de alta resolução não são alocações equivalentes. Um telefone pode falhar antes de um desktop. O conselho operacional verdadeiro é processar menos arquivos ou arquivos menores após um tempo limite ou falha de memória, e não publicar uma contagem máxima ou limite de megapixels não suportado.
Conclusão: trabalho pesado, interface silenciosa - como o Image Converter & Compressor realiza conversões fora do thread principal do seu dispositivo
A interface permanece mais silenciosa porque o pipeline repetido é executado em um trabalhador, sua tela pode ficar fora da tela e buffers de bytes grandes viajam como transferíveis. Essas são propriedades de origem concretas, não uma abreviação de marketing. Eles explicam onde o trabalho ocorre e como o progresso retorna, sem afirmar que cada navegador o programa de forma idêntica.
Teste a arquitetura com as imagens que seu fluxo de trabalho realmente usa. Observe os controles durante a conversão, confirme o progresso por arquivo, inspecione falhas e verifique o painel Rede em busca do marcador de teste. O design de ToolAcre fornece evidências observáveis: um módulo de trabalho real, saídas medidas e bytes de download locais, em vez de um trabalho remoto opaco.