Os fabricantes de navegadores vendem velocidade com números. A página do Safari da Apple chama o Safari de “o navegador mais rápido do mundo” e, com base em testes da Apple de agosto de 2026, afirma renderizar 5,3x mais rápido que o Chrome no macOS no MotionMark, um benchmark que “se concentra no desempenho gráfico”. O Google relatou “uma melhoria de 22% desde agosto de 2024” no Speedometer e estimou que isso poupa 116 milhões de horas de espera para quem navega 10 minutos por dia. Em junho de 2026, publicou pontuações recordes de 469 no JetStream e 61 no Speedometer. A Microsoft diz que, a partir da versão 134, “o Microsoft Edge é até 9% mais rápido, segundo a medição do benchmark Speedometer 3.0”. As equipes por trás do Blink, do Gecko e do WebKit construíram o Speedometer 3.0 juntas.

Você compara o Bromure Web com esses navegadores, então ele precisa acompanhar o ritmo deles.

Um navegador sem GPU

O Bromure Web roda o Chromium em uma VM Linux descartável no seu Mac. Até o Bromure 5, essa VM não tinha GPU.

O framework ParavirtualizedGraphics da Apple “implementa gráficos acelerados por hardware para o macOS executado em uma máquina virtual”, o caminho suportado para convidados macOS. Para convidados Linux, o framework Virtualization oferece um dispositivo gráfico Virtio que se configura com um tamanho de tela. Na nossa VM, ele dava ao Chromium uma tela e nenhuma aceleração 3D, então o Chromium recorria ao llvmpipe do Mesa, que roda OpenGL na CPU, e desligava a composição pela GPU. As páginas desenhavam os pixels certos, e mapas, gráficos em canvas, visualizadores 3D e ferramentas de design se arrastavam.

Como o Bromure 5 acrescenta uma GPU

O macOS 27 permite que um aplicativo implemente seu próprio dispositivo Virtio com VZCustomVirtioDeviceConfiguration. O Bromure 5 usa isso para apresentar uma GPU Virtio padrão (tipo de dispositivo 16), de modo que o convidado não precisa de nenhum driver de kernel personalizado. Ele usa o Ubuntu 24.04 e o módulo de kernel virtio_gpu de fábrica; a imagem de navegador compatível também inclui um Mesa de espaço de usuário fixado em versão e com patches, além da integração de vídeo do navegador.

Um quadro WebGL agora segue este caminho:

O Chromium desenha através do ANGLE no driver VirGL do Mesa.
O VirGL envia os comandos OpenGL pelas filas da GPU Virtio.
Um worker de renderização no Mac os reproduz através do ANGLE sobre o Metal.
A janela do navegador exibe os quadros prontos como IOSurfaces.

Um renderizador por VM. Cada VM de navegador ganha seu próprio processo de renderização em sandbox. Nos testes, dois workers reutilizaram os mesmos identificadores e mantiveram superfícies independentes, e o segundo continuou rodando depois que o primeiro foi fechado.
Cursor nativo. O macOS desenha o ponteiro a partir das imagens de cursor que o convidado envia.
H.264 em hardware. O Bromure liga o decodificador de vídeo do convidado ao VideoToolbox. O Chromium ainda decodifica AV1 em software.
Só gráficos. O dispositivo transporta renderização e decodificação de vídeo, e nenhuma computação geral na GPU, então o código na VM não consegue rodar cargas de aprendizado de máquina na sua GPU.

Os números

Rodamos uma mesma carga de trabalho WebGL de três formas em um único Mac: o Chrome na VM do Bromure com o novo renderizador, o Chrome na mesma VM com o dispositivo gráfico da Apple (e, portanto, com llvmpipe) e o Chrome no macOS.

Carga de trabalho	VM do Bromure, renderizador Metal	Mesma VM, gráficos Apple VZ (software)	Chrome nativo no macOS
2.048 desenhos de 64 × 64	20,8 ms	169,5 ms	12,9 ms
64 desenhos de 1.280 × 720, 32 iterações de shader	32,2 ms	965,2 ms	22,8 ms
24 desenhos de 1.920 × 1.080, 128 iterações de shader	68,2 ms	3.555,1 ms	63,9 ms

Cada valor é a mediana de cinco tentativas, em tempo real decorrido até concluir um lote de trabalho de GPU. Menor é melhor.

Gráfico de barras comparando os tempos medianos por lote WebGL do Apple VZ com llvmpipe, do Bromure com VirGL e Metal e do Chrome nativo do macOS com Metal em três cargas de trabalho — Tempo mediano por lote em cada carga de trabalho, em escala logarítmica. Cinza: a VM com o rasterizador por software llvmpipe. Roxo: a mesma VM com o renderizador Metal do Bromure. Azul: o Chrome nativo no macOS com Metal. As barras de erro marcam a mais rápida e a mais lenta de cinco tentativas.

Em comparação com a renderização por software, o novo caminho rodou 8,1x, 30,0x e 52,1x mais rápido, e a diferença cresceu com o trabalho por pixel. Em comparação com o Chrome nativo, a VM levou 1,61x, 1,41x e 1,07x o tempo. Muitas chamadas de desenho pequenas são o que mais custa, e no shader mais pesado a VM ficou a 7% do nativo.

Configuração: Bromure 5.0.1 em um Apple M5 Pro com 18 núcleos de CPU e 64 GB, rodando o macOS 27.0.1. A VM rodava o Ubuntu 24.04 ARM64 com Mesa 25.2.8, 9 vCPUs e 4 GB. Os três caminhos usaram o Chrome 154.0.8037.57. Cada amostra faz primeiro um aquecimento e termina com uma leitura de um pixel que obriga a GPU a concluir, então os tempos cobrem o navegador, o driver e a leitura, e deixam de fora a compilação de shaders.

O mesmo vídeo 1080p em tela cheia em duas janelas do Bromure Web, filmado com um celular. À direita, o Bromure 4 desenhando em software. À esquerda, o Bromure 5 com o renderizador Metal. A câmera se move entre as duas telas.

Levar os quadros até a tela

Publicar no flush. Um convidado com GPU Virtio primeiro nomeia o recurso de scanout e faz o flush quando o conteúdo está pronto. Nossa primeira versão publicava no scanout e podia mostrar uma superfície pintada pela metade. Agora o Bromure atualiza a janela no flush.

Uma retenção limitada durante o redimensionamento. Em um novo tamanho, o primeiro quadro muitas vezes sai quase preto ou cheio de buracos, antes que a página seja repintada. Durante um redimensionamento, o Bromure mantém o quadro pintado anterior na tela por um tempo limitado enquanto o novo parece não pintado, e o host e o convidado cadenciam o redimensionamento juntos. A verificação tende a reter, então uma página escura pode atrasar por um instante durante um redimensionamento. Fora de um redimensionamento, os quadros aparecem na hora.

Em uma execução rastreada com quatro VMs, 24 abas e 40 visitas a sites, quatro gravações de 200 segundos não tiveram nenhum quadro quase preto.

Alfa do cursor. O Linux aloca imagens de cursor em um formato sem canal alfa e depois usa essa memória como um cursor com alfa. O renderizador mantém os valores de alfa que o convidado escreveu, então os cursores continuam transparentes.

Contrapressão. O convidado consegue enviar comandos 3D mais rápido do que o host os reproduz. O Bromure limita cada envio a 1 MiB e reutiliza uma única fila de comandos Metal para capturar quadros.

Como foi construído

O Astra 6.1 fez toda a implementação, rodando como dois agentes no Bromure: um no Mac e outro no Linux. Nós definimos os requisitos e testamos os resultados.

O agente do macOS construiu o renderizador, o dispositivo Virtio, e a apresentação e a entrada.
O agente do Linux construiu o empacotamento do Mesa e do VirGL, as verificações de pré-requisitos, e o agente de ponteiro e o observador de redimensionamento na VM.
Testes de regressão e revisão de código independentes verificaram o trabalho ao longo do caminho.

Os dois agentes trabalharam no mesmo branch de funcionalidade compartilhado. Eles trocaram mensagens, anexos, pedidos e evidências de teste entre os dois ambientes pelo sistema de mensagens entre agentes do Bromure. O host intermedeia, filtra e registra as mensagens e copia os arquivos anexados entre as máquinas. O futuro aplicativo Bromure Sidecar faz parte desse esforço mais amplo; vamos descrevê-lo quando for lançado.

Ligar e desligar

No Bromure 5, o renderizador Metal fica em Desempenho em cada perfil do Bromure Web. Ele vem ligado por padrão, inclusive nos perfis existentes.

Ele exige o macOS 27. No macOS 26 e anteriores, o Bromure continua renderizando em software.
O ajuste global continua sendo o interruptor principal, e as alterações valem para novas janelas.
Um perfil com ele desligado ganha sua própria VM no antigo caminho gráfico.
Uma imagem de VM precisa de um marcador indicando que nós a validamos para o novo renderizador. Sem ele, o Bromure volta ao software.

Verificamos o antigo caminho gráfico no macOS 27 e o testamos em um Mac com o macOS 26. O novo código exige o macOS 27 ou posterior.