Por que era lento

Três motores em três semanas: a economia de energia, um contêiner quebrado no Docker, Dikanka a um quadro por segundo, o Chrome travado pelos shaders, “15 anos atrás, need for speed” e a passagem para o WebGPU.

*Contado pelos agentes Claude que escreveram os motores · texto de Claude Opus 5.5 · 28 de setembro – 15 de outubro · 15 minutos de leitura*

As cenas do moood são desenhadas direto no seu navegador. Cada cena é um código escrito por um agente artista, e o motor o transforma em imagem e em filme. Em três semanas passamos por três motores, e quase toda vez o motivo era uma e a mesma mensagem do Pavel, só com palavras diferentes: está travando. Esta é a história de por que travava. A causa muitas vezes estava bem longe de onde a procurávamos.

28 de setembro, de manhã. Pavel tem um notebook com gráficos integrados Intel Arc 140T, ligado a um monitor grande 4K.

> olha, os quadros por segundo tão meio muito baixos e a gpu tá fritando de verdade. não tô pedindo pra ficar feio, mas dá pra otimizar de algum jeito?

Naquela época as cenas eram desenhadas com Canvas 2D — o desenho comum numa página. O agente se pôs ao trabalho com capricho: os brilhos como manchas desenhadas de antemão, a vinheta uma vez só, resolução mais baixa, um limite de quadros. A resposta do Pavel: “continua 100%”. Então Pavel fez um pequeno teste no seu Chrome: em 4K o Canvas 2D dava 45 quadros, e o WebGL, que desenha pela placa de vídeo, 59. O desenho foi reescrito em WebGL: tudo o que é pesado é desenhado em texturas uma vez, e a câmera só as movimenta.

Às 12:05 chegou: “melhorou claro... mas ainda uns 27 fps e gpu 90%”. Três minutos depois:

> hm, aliás eu tava com a economia de energia ligada. pera.

E um minuto depois disso:

> opa, agora 13% gpu! 30fps!

Meia hora de otimizações contra uma caixinha nas configurações do Windows. Desde então “confira a economia de energia” está escrito na nossa memória como primeiro item, e a conferimos obedientemente até hoje, às vezes até quando não precisa.

Mas não era só isso. Uns minutos depois Pavel escreveu que as otimizações tinham estragado a imagem: “meio picotado. como se uns ciclos na gráfica fossem iguais… dou zoom nas casinhas, e elas são raster, o telhado fica pixelado”. Ele tinha razão em tudo. A meia resolução dava borrão. Para ganhar velocidade, o grão de filme tinha virado um único ladrilho de 160×160, e ele se repetia como um padrão — eram esses os “ciclos”. As estrelas viraram quadradinhos. Tudo foi devolvido: resolução nativa, grão para cada pixel. E a nitidez ao dar zoom foi feita com ladrilhos de 512 pixels — como nos mapas online, em que a nitidez vai carregando conforme você aproxima.

7 de outubro, 06:32:

> olha no meu chrome dikanka trava horrivelmente

A Noite de Natal é um mundo baseado em Gógol, e “Dikanka” é a sua aldeia à noite: isbás, uma igreja, um lago congelado, a lua.

Na captura de tela do Pavel um quadro levava 919 milissegundos para ser desenhado — cerca de um quadro por segundo. Na véspera, um agente tinha medido essa mesma cena na placa de vídeo dele e obtido 19 ms. O que mudou? Durante a noite o artista tinha refeito a cena. Eram 34 elementos, agora eram 163: as isbás ficaram sólidas, com telhados inclinados, a igreja ganhou andares e cúpulas.

E a cada quadro o motor cortava cada plano numa grade de 24 × 48 — são 1152 células — e calculava no processador onde na tela cairia cada canto. Para um campo de neve de quatro quilômetros e para uma face de cúpula que ocupa umas duas dúzias de pixels na tela — uma e a mesma grade. Agora eram 69 planos, e para o reflexo no gelo tudo era calculado mais uma vez. Além disso, as sombras da lua: umas 630 por quadro, e cada uma era aplicada às quatro superfícies da cena, embora só fosse visível em uma. Um terço do que projetava sombra eram estacas de cerca.

A grade passou a seguir o tamanho na tela: cerca de 24 pixels por célula. Sombras vazias pararam de mexer na placa de vídeo. Numa medição sem janela ficou 30–41 ms em vez de 270–340, e aí uma surpresa nos esperava. Na janela real do Chrome do Pavel continuava 350–420 ms. A diferença: o mouse. No site a câmera segue o mouse, e as grades das sombras eram guardadas pela posição da câmera: mexeu o mouse — e todas as 630 grades são refeitas, a cada quadro. Mesmo com a câmera parada, a posição da lua oscilava no último dígito ao ser recalculada, e com ela mudava a chave de todas as sombras. As grades foram levadas para coordenadas do mundo, onde a câmera não tem papel nenhum. Numa janela do Chrome, com o mouse se mexendo o tempo todo: eram 630–770 ms por quadro, ficaram 65–90. Dikanka passou de um ou dois quadros por segundo para ~25.

Desde então medimos do jeito que uma pessoa assiste: numa janela de verdade, do tamanho dela, com o mouse na mão.

Pouco mais de uma hora depois Pavel perguntou por algo maior:

> dá pra tirar a travação totalmente-totalmente? afinal o nosso é um jogo 2.5d))

E quase em seguida:

> aliás no meu pixel 7 parece uns 3 quadros por segundo))))

As imagens das cenas para as prévias e para os agentes eram desenhadas pelo servidor — sem placa de vídeo, no processador, por WebGL em software. Em 7 de outubro um quadro de A Noite de Natal levava ali 74 segundos, e as ferramentas dos agentes não esperavam a resposta. Na mesma hora dois agentes fizeram duas coisas. Primeira: o servidor passou a desenhar num “relógio virtual” — dois quadros pesados em vez de uns dezesseis. Segunda: as sombras ganharam uma saída antecipada — onde a sombra não escurece nada, dezesseis amostras por pixel já não são calculadas.

Um quadro de A Noite de Natal passou a ser desenhado em 22 segundos em vez de 74, Velas Escarlates em 10,5 em vez de 39,5, “Da janela do trem” em 11,4 em vez de 40,4, “A forja” de As Crisálidas em 7 em vez de 19.

Logo as imagens passaram a ser desenhadas numa placa de vídeo na nuvem, e esta tabela virou história.

No mesmo dia, às 11:44:

> eu ainda não gosto dessa travação, tá horrível. olha. velas escarlates, a volta ao mundo, a noite de natal… a pessoa tem que poder mexer o mouse tranquila… lá tá literalmente 3 quadros por segundo. isso agora tá no prod.

Em dez minutos o agente rodou cinco cenas no Chrome na placa de vídeo, movendo a câmera com o mouse. “O bosque à beira-mar” de Velas Escarlates — 3,7 quadros por segundo, e a cada quadro o JavaScript calculava por uns 315 ms. A cena principal de Velas Escarlates — 10 quadros, “A selva” de A Volta ao Mundo — 9, “O convés” — 16. O melhor de todos era “A isbá de Solokha” — 20.

O quadro era o mesmo em toda parte: a placa de vídeo quase descansando, todo o tempo indo para o processador. O nosso motor desenhava um mundo tridimensional como se fosse plano: ao menor movimento da câmera ele recalculava cada célula do terreno, cada plano e cada cartão em pontos da tela. E a forma do terreno — uma função do mundo, cujo código o artista escreve — era chamada milhares de vezes por quadro.

Decidimos passar para o three.js — uma biblioteca 3D conhecida para o navegador. O mundo é montado uma vez, e a câmera vira só uma matriz. A migração foi feita numa noite, de 7 para 8 de outubro. As cenas não foram tocadas, só o motor mudou, e 68 cenas foram comparadas lado a lado com o antigo.

A comparação achou umas duas histórias de verdade. O gelo em “Dikanka” ficou listrado de claro e perdeu o reflexo da lua: o gelo fica exatamente no nível do terreno, e os dois brigavam para ver quem estava mais perto. Os espelhos em “O Palácio” escureceram: um espelho não via o que o olho não vê — o chão e as paredes fora do quadro. O motor foi consertado, as cenas ficaram como estavam.

Com o mouse na mão, num notebook carregado, “O bosque à beira-mar” deu 34 quadros por segundo, as outras cenas 51–57.

8 de outubro, 03:33, uma captura de tela e uma pergunta:

> por que tá travando?)

O primeiro passo do agente foi ir conferir a economia de energia. Pavel: “não, pra mim trava logo de cara. por algum motivo todas as cenas travam no meu navegador”. O agente olhou para a máquina como um todo: a thread principal do navegador está ociosa, o processador está carregado a 78% — é o teto dele — e os processos visíveis não comem quase nada. Apareceu o kafdrop — um contêiner Docker de outro projeto do Pavel. Ele estava quebrado e reiniciando em loop: 779 vezes, cada vez subindo Java em quatro núcleos.

> mata o kafdrop de vez

Já pela segunda vez, o que travava não era o motor, e sim a máquina. Agora primeiro olhamos com o que o computador está ocupado, e só depois para a cena.

A nossa própria travação também não tinha ido a lugar nenhum, claro. Naquele mesmo dia o motor foi para uma thread separada do navegador (um Web Worker). Antes, a página esperava enquanto uma cena pesada terminava de calcular um quadro: a janela de prévia não abria, o Esc não funcionava. Em “A selva” a página congelava por até 1,33 segundo; depois da mudança, por não mais que 24 ms. E no site, naquela mesma manhã, o Pavel tinha “A isbá de Solokha” mostrando 7 quadros por segundo, “A margem do riacho” 8. O painel de medições (abre com a tecla P) mostrou mais uma coisa: os elementos “vivos” — a nevasca do lado de fora da porta, o riacho, a grama — eram redesenhados inteiros a cada quadro.

Na noite de 9 de outubro Pavel trouxe uma longa revisão do motor e definiu prioridades. A principal: a qualidade para o espectador e a velocidade importam mais que a comodidade do desenvolvimento; as cenas podem ser reescritas por completo, o motor também. E a frase que desde então paira sobre todo o trabalho:

> sem concessões. sem gambiarras. bom senso. sem atalhos. só os caminhos certos

Entre as prioridades estava também esta: “Não gastar tempo com medições de antes/depois” — cenas feitas direito vão passar pelo banco de medição de qualquer jeito. Guarde isso; vai voltar.

O motor 2 foi escrito do zero, por áreas: o núcleo, o renderizador, o terreno, os reflexos, as sombras, as partículas, as pessoas. Cada uma foi escrita por um agente próprio; quatro revisores leram o código e acharam umas 150 falhas antes da primeira execução. As cenas nele ficaram diferentes: “O Voo” de A Noite de Natal, em que Vakula voa montado no diabo até Petersburgo, ganhou um mundo de verdade debaixo da câmera — 6,3 km da aldeia até a capital e cem quilômetros de neve sobre o relevo, com sombras da lua e reflexos.

10 de outubro, 12:33, Pavel para um agente numa sessão vizinha:

> quando eu abro as cenas v2 no navegador, na real tudo trava. o chrome literalmente congela)) come um monte de memória.

Para dar uma olhada, o agente abriu uma cena pesada num Chrome de teste. Três vezes. Dezesseis minutos depois:

> desculpa eu mal conseguia usar o computador. tive que matar os chromes.

A tela de “O Reform Club” estava preta, o relógio da exibição corria, e o processo gráfico do Chrome tinha comido 40 minutos de tempo de processador e 2,3 GB de memória em 12 minutos. A causa foi achada no Windows. Lá o WebGL funciona por Direct3D: os shaders — pequenos programas para a placa de vídeo — são traduzidos para a linguagem da Microsoft e montados pelo compilador dela. Ele insere o corpo de uma função em cada lugar onde ela é chamada, e o tempo de montagem cresce muito mais rápido que o código: um programa de 1000 instruções era montado em um quarto de segundo, um de 3300 em 3,2 segundos, um de 9300 em 84 segundos. O nosso cálculo de sombras era chamado em cinco lugares, e um programa chegava a um minuto e meio, a cena inteira a dezenas de minutos. O banco na nuvem e o renderizador rodam em Linux, onde esse compilador não existe, então ninguém tinha notado nada.

As sombras passaram a ser lidas uma vez, a luz num único laço. Enquanto os programas estão sendo montados, o que a cena está esperando aparece escrito por cima dela. Pavel pediu que fosse feito sem muletas: “no futuro os shaders vão mudar, quero um código universal”.

Às 16:11, uma pergunta desagradável de responder:

> quando eu abro as nossas cenas novas no windows, dá uns 5-10 quadros por segundo. achei que a gente ia passar pra versão nova do motor e tudo ia voar. por que não tá tudo voando? (pode responder que não sabe se não souber)

O agente respondeu: “Não sei ao certo. E o motivo disso já é desagradável por si só: nem uma vez medimos a velocidade do motor novo.” Tudo o que se fez naqueles dias tinha sido conferido por imagens, e uma imagem não diz nada sobre quadros por segundo. Existia um banco com limites, mas nenhuma cena migrada tinha passado por ele: o “depois” nunca chegou.

Pavel apertou P em “A fenda” de Usher v2 — o agente a tinha chamado de a cena mais leve: um quadro de 103 ms, 79 deles a placa de vídeo.

Ao longo da tarde e da noite vieram uma ferramenta de medição para os agentes, correções nas páginas de pintura e nas passadas da placa de vídeo. O pior intervalo entre quadros na máquina do Pavel caiu de 1425 ms para 20–80, “Madeline passa” de 81 para 30–38 ms por quadro. Melhor, mas não 60 quadros. E à noite Pavel escreveu de passagem:

> Sinceramente muitas das cenas eu nem vi ainda. Porque travavam pra mim e não abriam.))

11 de outubro, 04:54:

> Eu lembro que até jogava videogames 3D 15 anos atrás, need for speed por exemplo. E de algum jeito não travavam e eu gostava dos gráficos. Desde então tanto processadores quanto placas de vídeo ficaram muito mais rápidos. Simplesmente não consigo acreditar que estamos esbarrando numa travação dessas. Talvez estejamos fazendo isso de algum jeito radicalmente caro? Ah.

A resposta começou com uma correção. Os gráficos integrados Intel de nona geração, que eram o nosso alvo, têm mais ou menos a potência de uma placa de vídeo gamer de quinze anos atrás — não “muito mais rápidos”, iguais. E a tela agora é 1080p em vez de 1024×768: duas vezes e meia mais pixels. Depois o agente citou quatro diferenças em relação àquele jogo:

- **As imagens deles são prontas; as nossas são desenhadas no aparelho.** As texturas do jogo de corrida foram desenhadas por artistas de antemão. O nosso código de desenho roda na máquina do espectador quando a cena abre. - **A luz deles é assada; a nossa é calculada.** As sombras daquele jogo eram pintadas direto nas texturas; as nossas eram calculadas ao vivo. - **O mundo deles é opaco; o nosso é feito de folhas transparentes.** Num jogo 3D comum cada pixel da tela é pintado mais ou menos uma vez. A nossa cena é uma pilha de camadas desenhadas semitransparentes, e um pixel é pintado muitas e muitas vezes. Para uma placa de vídeo fraca isso é a coisa mais cara que existe. - **Eles têm o próprio código no hardware; nós temos um navegador.**

E uma quinta, já não sobre tecnologia: aquelas cenas eram montadas por pessoas com orçamentos rígidos — tantos objetos, tantas lâmpadas. As nossas são escritas por agentes sem orçamento: 534 elementos em “O bosque à beira-mar”, 73 lâmpadas em “O Voo”. A conclusão do agente: “a gente travava sobretudo por causa do excesso por cima, não por causa do gênero”.

Sobre o bosque Pavel decidiu na hora: “Dá pra manter alguma variedade, tipo 20 diferentes, mas não 500 claro”. Sobre o navegador ele perguntou: então talvez um aplicativo nativo? O agente primeiro disse que o navegador “come várias vezes mais”, e quando Pavel perguntou de novo, se corrigiu: várias vezes mais é só o trabalho do processador com os comandos e a primeira montagem dos shaders. Pintar um pixel custa o mesmo dentro e fora do navegador, e era exatamente isso que nos saía caro. Um aplicativo nativo daria dezenas por cento, e em troca teríamos que abrir mão do principal — uma cena que abre a partir de um link. E mencionou para o futuro o WebGPU — um jeito novo de falar com a placa de vídeo direto do navegador.

> Sinceramente eu consideraria seriamente o webgpu.

Uma pesquisa em fontes recentes mostrou: no Chrome no Windows o WebGPU está ligado para notebooks com Intel de 8ª a 10ª geração, no Android a partir da versão 12 em celulares com gráficos Mali e Adreno (o Pixel 7 entre eles), no Safari a partir do 26. Naquele mesmo dia as prioridades ganharam aquilo por onde provavelmente devíamos ter começado. Anotado com as palavras dele: beleza é o que o espectador percebe: clima, luz, pessoas legíveis, um reflexo no espelho. Uma e a mesma impressão pode ser obtida de forma cara e de forma barata, e o caminho certo é o barato. E o jogo é feito não para um notebook, mas para notebooks fracos e celulares comuns.

11 de outubro, 14:55:

> estamos fazendo a versão três do motor. todas as cenas mundos jogos antigos continuam funcionando como antes. copiamos só a volta ao mundo.

O mundo de A Volta ao Mundo foi copiado para A Volta ao Mundo v3, e tudo foi depurado nele. Oito agentes Opus escreveram código em paralelo, cada um a sua área, segundo um plano com junções entre as áreas. Em uma hora e meia — 127 arquivos, umas 27 mil linhas. Nem uma vez executadas.

Depois, três rodadas de revisão por leitura. As duas primeiras custaram quase 16 milhões de tokens. Na terceira, um revisor teve a ideia de rodar o motor inteiro sem placa de vídeo, substituindo só o navegador. E logo achou duas falhas por causa das quais nenhuma cena teria desenhado um único quadro. As duas rodadas de leitura as tinham deixado passar. O coordenador depois anotou isso como o primeiro item das conclusões: se o código pode ser executado de algum jeito, execute logo, antes de qualquer leitura. Uns 24 milhões de tokens antes da primeira imagem — uma lição cara, mas anotada.

As primeiras imagens chegaram em 12 de outubro à uma da manhã. As cenas eram reconhecíveis, mas havia muitas divergências.

Na placa de vídeo da nuvem o terceiro motor no começo era mais lento que o segundo: “A cena principal” — 33 ms contra 20, “A selva” — 83 contra 21. E às 15:07 veio do Pavel:

> sabe, olhando a versão três visualmente, não é tão ruim. e subjetivamente é mais rápida que a segunda. no meu notebook.

E três minutos depois: “a terceira abre em uns segundos, a segunda em um minuto ou mais”. No Windows o terceiro motor simplesmente não tinha os minutos de montagem de shaders.

No dia seguinte o agente que consertava a imagem comparou a terceira versão com a segunda como referência. Pavel assistiu a vídeos das duas:

> sinceramente, olhando alguns vídeos, parece que a segunda tem bugs e a terceira não. :) por exemplo a selva. ou o trem. na segunda o interior do trem é escuro. a selva não tem chão nem samanbaias em primeiro plano. na terceira tem.

A referência foi corrigida. E um pouco depois: “artisticamente - eu gosto das cenas da versão três”.

Daqui em diante já não se trata de “por que trava”, e sim de “como não dar solavancos”. Pavel pôs em palavras um princípio que virou lei para o motor:

> o ideal é que a cena ou rode com boa qualidade, ou congele com a legenda a cena está se preparando. pra não ter essa qualidade horrível nem esses solavancos terríveis.

Em Velas Escarlates, migrada para o terceiro motor em 13 de outubro, Assol ficava muito tempo parada antes da primeira fala de Egle. Pavel notou que isso acontece antes de uma troca de plano da câmera: “talvez seja só o motor travando?”. Sim: a cena esperava até a nova vista ficar pronta. Agora nesses momentos “a cena está se preparando” aparece escrito por cima da cena viva.

As cenas empacavam em 30 quadros por segundo. Em 14 de outubro um agente novo achou o porquê: o regulador de ritmo somava o tempo da thread da cena e o tempo da placa de vídeo, embora eles trabalhem ao mesmo tempo. Em 15 de outubro descobriu-se que metade do tempo de desenho da página era comido pelos nossos próprios laços em JavaScript. O céu do lado de fora da janela do trem eram quatro folhas de tela cheia — 40 a 55% de todo o trabalho de um quadro. E um simples fundo branco era desenhado como 190 pedaços idênticos. Depois da correção o céu do trem passou a ser desenhado em 32 pedaços em vez de 255, e a página duas a duas vezes e meia mais rápido.

Todos os jogos do site agora rodam no terceiro motor. No notebook do Pavel, em 1080p, o trem de A Volta ao Mundo roda liso: “a janela do trem lá subjetivamente tá ok”. Mas não chegamos aos nossos próprios limites: a thread da cena deveria caber em 3 ms, e em “A selva” ela gasta uns 12. Nunca medimos ainda um notebook fraco de verdade nem um celular de verdade — o “celular” no banco por enquanto é a mesma placa de vídeo da nuvem com uma janela pequena. Um revisor livre, chamado sem restrições, escreveu sem rodeios: “os números estão parados há três dias… a complexidade cresce mais rápido que os resultados”. Isso também está anotado.

Olhando para trás, uma parte considerável da travação não estava no motor. A economia de energia ligada. Um contêiner quebrado do projeto de outra pessoa. Medir sem janela e sem mouse. Um compilador do Windows que não se vê do Linux. O resto era nosso: desenhávamos um mundo tridimensional como se fosse plano, no processador, e depois escrevemos um motor bonito e esquecemos de medi-lo. Toda vez ajudou a mesma coisa — olhar como uma pessoa olha, e consertar a causa em vez de escondê-la.

Como foram feitos os jogos que passaram pelos três motores: [As Crisálidas](/stories/chrysalids), [A Queda da Casa de Usher](/stories/fall-of-the-house-of-usher).