Divisor de imagem em grade

O divisor de grade de imagem separa uma foto em partes iguais, geralmente um conjunto 3×3 com nove imagens para redes sociais. Quando as peças são publicadas na ordem correta em plataformas como Instagram, WeChat Moments ou Weibo, a visualização do perfil ou feed recompõe a imagem grande original. Ele é útil para campanhas visuais, teasers de produto, anúncios de eventos, portfólios e composições em que o conjunto importa mais que uma postagem isolada. Bons resultados dependem da proporção da imagem, das margens para rostos e textos e da ordem de envio, pois uma peça fora do lugar quebra o efeito.

O divisor de imagem em grade é construído sobre o HTML5 Canvas 2D API (WHATWG HTML Living Standard §4.12, originalmente especificado na Recomendação W3C HTML5 de 2014). O pipeline tem três camadas: decodificar os pixels de origem em um CanvasImageSource, copiar um sub-retângulo desses pixels para um canvas offscreen via a forma de 9 argumentos de drawImage e então codificar o canvas offscreen como PNG via canvas.toBlob(). Tudo acontece na aba do navegador — sem upload, sem servidor, sem renderização remota. A etapa de decodificação importa mais do que parece. Um File de <input type='file'> ou um DataItem de arrastar e soltar é lido por FileReader.readAsDataURL (ou, em código moderno, URL.createObjectURL) em uma Blob URL, que o navegador entrega ao carregador de Image. O elemento Image dispara 'load' assim que o bitmap é decodificado pelo codec de imagem da plataforma (libpng/libjpeg-turbo/libwebp no Chromium, o equivalente no WebKit/Gecko). Uma imagem sem CORS carregada dessa forma é tratada como 'contaminada' — getImageData lançaria um SecurityError — então o divisor usa apenas drawImage e nunca lê arrays de pixels, o que contorna completamente o problema de CORS. Para imagens muito grandes (>~8K no lado mais longo) o bitmap é mantido na memória da GPU em alguns motores, então canvas.toBlob pode passar por uma leitura GPU→CPU que custa ~30-100 ms em um celular. O recorte é uma única chamada drawImage por fatia: ctx.drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) — os três primeiros pares são o retângulo de origem (sx, sy, sw, sh) e os três últimos são o retângulo de destino no canvas de destino. Para uma divisão 3×3 de uma foto 1920×1080, o retângulo de origem de cada fatia é 640×360 começando em (col*640, row*360). O canvas de destino é dimensionado exatamente para a fatia (640×360) e então canvas.toBlob(blob => ..., 'image/png') executa o codificador PNG da plataforma. PNG é escolhido em vez de JPEG porque as fatias de grade são tipicamente recortes retangulares limpos com texto nítido e elementos de UI onde a codificação sem perdas importa; os blocos DCT 8×8 do JPEG borrariam as bordas. O download em lote usa URL.createObjectURL em cada Blob, um clique sintético de <a download> e revokeObjectURL após um pequeno atraso (geralmente 60-120 s, o tempo de vida da plataforma para uma Blob URL não utilizada). Para 9 fatias, isso dispara 9 eventos de download consecutivos; alguns navegadores limitam múltiplos downloads da mesma aba, então a página normalmente os espaça com um setTimeout de 50-200 ms entre cliques. Em termos de desempenho, o gargalo em um celular é geralmente o codificador PNG (libpng é single-threaded por codificação), não drawImage; para 9 fatias de 1080p, espere 200-500 ms no total em um Android intermediário e 100-200 ms em um Chromium desktop.

• Pipeline: FileReader ou URL.createObjectURL → elemento Image → HTMLCanvasElement → recorte drawImage de 9 argumentos → canvas.toBlob('image/png') → URL.createObjectURL + <a download>.
• drawImage(img, sx, sy, sw, sh, dx, dy, dw, dh) é a sobrecarga de 9 argumentos que recorta um retângulo de origem (sx,sy,sw,sh) em um retângulo de destino (dx,dy,dw,dh); essa é a única chamada de API que realiza a divisão.
• Imagens de origem que não são servidas com cabeçalhos CORS contaminam o canvas — getImageData lançaria SecurityError, então o divisor nunca lê arrays de pixels, apenas faz blits e codifica.
• canvas.toBlob é assíncrono e não bloqueante (o callback dispara em uma microtask posterior) versus o legado canvas.toDataURL que é síncrono e congela a thread principal para imagens grandes.
• Para uma divisão 3×3 de uma imagem N×M, cada fatia é (N/3) × (M/3); tamanhos não divisíveis produzem um restante de 1 pixel na borda direita/inferior, tratado com Math.floor com uma fatia de restante explícita se necessário.
• PNG é escolhido em vez de JPEG para fatias de grade porque cada fatia é um recorte retangular com bordas nítidas (texto, UI, diagramas) onde os blocos DCT 8×8 borrariam as linhas de limite.
• Download em lote usa URL.createObjectURL por blob + clique de <a download>; navegadores limitam múltiplos downloads da mesma aba, então a página normalmente espaça os cliques em 50-200 ms e revoga as Blob URLs após o clique para liberar memória.
• O gargalo de desempenho é o codificador PNG da plataforma (libpng é single-threaded por codificação), não drawImage; 9 fatias de 1080p levam ~200-500 ms em mobile intermediário e ~100-200 ms em Chromium desktop.