Caras, parabéns pelo nível do post! É muito raro ver alguém abrindo os desafios reais de WebGPU e WebCodecs com essa profundidade em vez de só soltar um pitch raso de "mais um app com IA".
O ponto 4 sobre inicializar as sessões do ONNX de forma serial me chamou muita atenção. Na teoria parece tentador mandar um Promise.all() em tudo na inicialização, mas estourar a memória/VRAM logo de cara — especialmente em GPUs integradas mais modestas (Intel Iris / AMD Vega) — é uma dor de cabeça clássica de quem tenta levar computação pesada pro client-side.
Fiquei com duas dúvidas bem práticas sobre o dia a dia do projeto:
Recuperação de contexto: Como vocês estão tratando o device.lost da WebGPU quando o navegador estrangula recursos em segundo plano ou a GPU reinicia o driver? Conseguem reidratar o pipeline sem forçar um reload bruto da aba?
Heurística de fallback: A decisão de cair pra WASM quando o WebGPU fica instável é feita por uma checagem em tempo de execução (tipo um benchmark/teste rápido de warmup) ou vocês deixam uma flag/toggle manual pro usuário caso o preview engasgue?
A ideia de ter o agente e a CLI compartilhando exatamente o mesmo motor da timeline foi uma sacada excelente. Vou clonar o repositório pra dar uma olhada com calma no código!
1
1
Muito obrigado pelo comentário e pelas excelentes perguntas!
- Recuperação de contexto: monitoramos o device.lost, interrompemos as tarefas em andamento e reconstruímos o adapter/device e as sessões ONNX de forma sequencial. Como os modelos e o estado da timeline permanecem em cache, normalmente não é necessário recarregar a página.
- Fallback: a troca para WASM considera falhas na inicialização, no warmup e durante a execução — não apenas uma queda isolada de desempenho. Também mantemos uma opção manual para dispositivos estáveis, mas com desempenho insatisfatório.
E sim, compartilhar o mesmo motor de timeline entre o Agent e a CLI é essencial para garantir resultados consistentes. Obrigado novamente — será ótimo receber seu feedback sobre o código!