Criei este projeto para testar o poder de integrar modelos generativos de última geração, como o Gemini 2.0 Flash Image e o Gemini 2.5 Flash (apelidado de “Nano Banana”), com um editor de imagem relativamente simples escrito em tecnologias web. O experimento confirmou que a combinação é potente: qualquer pessoa com um navegador e uma API key consegue gerar, editar e combinar imagens em minutos usando apenas linguagem natural — sem instalar software pesado ou dominar pipelines de ML.

Painel de camadas: cada iteração de prompt vira uma nova camada com ajuste independente de blend mode e visibilidade.

Stack tecnológica

• Frontend: HTML5 Canvas API para renderização/manipulação, CSS3 com efeitos glassmorphic (backdrop-filter, transparências) e Vanilla JS ES6+ — hoje com ~6,3k linhas.
• Machine Learning & APIs: Google Gemini 2.0/2.5 para geração e edição via REST, ONNX Runtime Web 1.17.1 para rodar modelos no navegador, SAM (Segment Anything) em ONNX para segmentação inteligente e WebAssembly como backend de inferência.
• Armazenamento: IndexedDB faz cache persistente dos modelos (~40 MB), Map() mantém imagens de camadas em memória e Blob URLs cuidam dos assets temporários.

Interface principal: ferramentas tradicionais convivem com atalhos para prompts e inpainting diretamente sobre o canvas.

Descrição e potencial

O editor evidencia como APIs generativas podem democratizar edição profissional. O usuário alterna entre ferramentas tradicionais (pincel, borracha, transformações) e prompts de linguagem natural para inpainting contextual ou geração de elementos inéditos. O sistema de camadas não destrutivo com blend modes, a seleção mágica baseada em SAM e a interface glassmorphic inspirada em iOS/macOS entregam uma experiência que parece nativa, mas roda inteiramente no navegador.

Resultado final: composição híbrida unindo geração de novos objetos (trono e armadura) com retoques manuais.

Autocrítica e limitações atuais

Gargalos de performance

1. Renderização síncrona — Treze chamadas sequenciais de canvas.toDataURL() travam a thread principal durante a exportação, deixando a UI congelada, especialmente em mobile.
2. Inferência SAM lenta — A seleção mágica leva 2–5 s porque o ONNX Runtime opera em WASM single-thread (falta isolamento cross-origin). O objetivo seria < 500 ms.
3. Rendering de camadas — Cada frame re-renderiza todas as camadas, sem caching incremental. Passou de 60 FPS para < 15 com mais de dez camadas.
4. Gerência de memória — O cache manual sem LRU e sem limpeza consistente de Blob URLs acumula memória e eventualmente derruba o navegador em projetos grandes.

Limitações de produto

• Resolução máxima limitada a 1024×1024 px (restrição do Gemini) — não atende workflows profissionais em 4K/8K sem dividir em tiles ou integrar outros modelos.
• Sem responsividade — Layout fixo desktop; tablets e smartphones ficam de fora, o que corta boa parte do público potencial.

Conclusão e próximos passos

A prova de conceito mostrou que misturar APIs generativas com um editor web é viável e oferece uma UX competitiva. Ao mesmo tempo, o código monolítico, o excesso de estado global e a ausência de testes deixam a base frágil. Antes de pensar em features novas, preciso de um refactor sério: modularizar em um modelo tipo MVC, isolar estado com Proxy, tornar operações bloqueantes assíncronas, implementar cache LRU, habi­litar cross-origin isolation para liberar threading no WASM e escrever uma suíte de testes. Só depois disso o ImageX pode virar produto.