Three.js r184 recebe HTMLTexture: DOM ao vivo como superfície 3D
O Three.js r184 foi lançado esta semana. O grande destaque é uma nova classe HTMLTexture, que permite apontar o Three.js para qualquer elemento HTML ao vivo e usá-lo como textura em uma malha. Os botões continuam clicáveis, os campos de entrada continuam recebendo foco, as animações CSS continuam rodando e o navegador lida com acessibilidade e IME como sempre fez.
Apresentação oficial do Chrome sobre a API HTML-in-Canvas que serve de base para a HTMLTexture do Three.js
HTMLTexture em um parágrafo
A HTMLTexture encapsula a API HTML-in-Canvas do Chrome 146. Você fornece a ela um elemento DOM. O Three.js define layoutsubtree no canvas, insere o elemento no DOM do renderizador e projeta a saída rasterizada em uma THREE.Texture, que pode ser amostrada por qualquer material no WebGL 2 ou WebGPU. Os exemplos oficiais (webgl_materials_texture_html e webgpu_materials_texture_html) incluem texto formatado, imagens, SVG, um campo de entrada funcional e um botão.
Na prática, isso significa que componentes React, widgets de design systems, players de vídeo, gráficos ou páginas incorporadas inteiras podem aparecer em uma tela curva, um painel publicitário ou um painel de interface dentro de uma cena Three.js, sem a limitação habitual de “rasterizar em um canvas e abrir mão da interatividade”.
A ressalva
O recurso só funciona onde a API subjacente está disponível. No momento, isso significa Chromium 146 ou superior com a flag chrome://flags/#canvas-draw-element ativada, portanto sites em produção ainda precisam de uma alternativa. O PR mantém essa possibilidade em aberto ao fazer com que a HTMLTexture falhe de forma controlada quando a API não está disponível, mas é recomendável detectar a compatibilidade do recurso antes de prometer aos clientes um painel Three.js totalmente interativo.
Safari e Firefox ainda não indicaram prazos. Considerando que o próprio WebGPU só alcançou compatibilidade básica nos três navegadores no fim de 2025, a adoção do HTML-in-Canvas provavelmente seguirá uma trajetória semelhante, de cerca de dois anos.
Uma demonstração da comunidade do HTML-in-Canvas anterior à chegada do wrapper do Three.js
O outro destaque: zero alocações por quadro
A mudança menos chamativa, mas possivelmente mais importante, está no caminho crítico do renderizador. Antes da r184, renderizar 1.000 malhas a 60 FPS podia alocar entre 240.000 e 500.000 objetos descartáveis por segundo. O coletor de lixo precisava lidar com isso em todas as cenas executadas por longos períodos. A r184 elimina essas alocações do loop principal de renderização. Sessões longas de WebXR, visualizadores de construções densas e qualquer cena que permaneça ativa por mais de 30 segundos ganham gratuitamente uma melhoria real no tempo de quadro.
Outras mudanças menores que merecem destaque
A AnimationAction agora preserva as configurações do interpolador durante a criação, portanto inverter o timeScale não causa mais saltos. O AudioLoader não entra mais em condição de corrida com o gerenciador de carregamento. BatchedMesh e InstancedMesh deixam de gerar erros em getColorAt quando nenhuma cor foi definida. Os caminhos de renderização obsoletos para instanciamento em WebGL foram removidos de vez. Os exemplos ganharam uma piscina de bolas com SSGI, nuvens volumétricas no carregador de 3D Tiles e inclinação lateral na câmera da montanha-russa.
O que faríamos com isso
Para a Cinevva, o caso de uso mais interessante é uma interface dentro do canvas para o player de reels e as ferramentas de criação. Atualmente, sobrepomos HTML ao Three.js. Com a HTMLTexture, a sobreposição do chat, o navegador de assets e o campo de prompt podem ficar em geometrias dentro da cena sem perder a navegação pelo teclado. Assim que a API chegar à versão estável do Chrome sem exigir uma flag, implementaremos uma variante controlada por feature flag.