Bromure 5 le da una GPU al navegador

Los fabricantes de navegadores venden velocidad con cifras. La página de Safari de Apple lo llama “el navegador más rápido del mundo” y, a partir de pruebas de Apple de agosto de 2026, afirma que renderiza 5,3x más rápido que Chrome en macOS en MotionMark, un benchmark que “se centra en el rendimiento gráfico”. Google anunció “una mejora del 22% desde agosto de 2024” en Speedometer y calculó que ahorra 116 millones de horas de espera a los usuarios que navegan 10 minutos al día. En junio de 2026 publicó puntuaciones récord de 469 en JetStream y 61 en Speedometer. Microsoft dice que, desde la versión 134, “Microsoft Edge es hasta un 9% más rápido según el benchmark Speedometer 3.0”. Los equipos de Blink, Gecko y WebKit crearon Speedometer 3.0 juntos.

Usted compara Bromure Web con esos navegadores, así que tiene que estar a su altura.

Un navegador sin GPU

Bromure Web ejecuta Chromium en una VM de Linux desechable en su Mac. Hasta Bromure 5, esa VM no tenía GPU.

El framework ParavirtualizedGraphics de Apple “implementa gráficos acelerados por hardware para macOS ejecutándose en una máquina virtual”, la vía admitida para invitados macOS. Para invitados Linux, el framework Virtualization ofrece un dispositivo gráfico Virtio que se configura con un tamaño de pantalla. En nuestra VM le daba a Chromium una pantalla sin aceleración 3D, así que Chromium recurría a llvmpipe de Mesa, que ejecuta OpenGL en la CPU, y desactivaba la composición por GPU. Las páginas dibujaban los píxeles correctos, y los mapas, las gráficas en canvas, los visores 3D y las herramientas de diseño iban a paso de tortuga.

Cómo añade Bromure 5 una GPU

macOS 27 permite a una aplicación implementar su propio dispositivo Virtio con VZCustomVirtioDeviceConfiguration. Bromure 5 lo usa para presentar una GPU Virtio estándar (tipo de dispositivo 16), así que el invitado no necesita ningún driver de kernel a medida. Usa Ubuntu 24.04 y el módulo de kernel virtio_gpu de serie; la imagen de navegador compatible incluye además un Mesa de espacio de usuario con versión fijada y parcheado, y la integración de vídeo del navegador.

Un fotograma WebGL sigue ahora este camino:

1. Chromium dibuja a través de ANGLE sobre el driver VirGL de Mesa.
2. VirGL envía los comandos OpenGL por las colas de la GPU Virtio.
3. Un proceso de renderizado en el Mac los reproduce a través de ANGLE sobre Metal.
4. La ventana del navegador muestra los fotogramas terminados como IOSurfaces.

• Un renderizador por VM. Cada VM del navegador tiene su propio proceso de renderizado aislado. En las pruebas, dos procesos reutilizaron los mismos identificadores y mantuvieron superficies independientes, y el segundo siguió funcionando después de que se cerrara el primero.
• Cursor nativo. macOS dibuja el puntero a partir de las imágenes de cursor que envía el invitado.
• H.264 por hardware. Bromure conecta el decodificador de vídeo del invitado con VideoToolbox. Chromium sigue decodificando AV1 por software.
• Solo gráficos. El dispositivo transporta el renderizado y la decodificación de vídeo, y nada de cómputo general en la GPU, así que el código de la VM no puede ejecutar cargas de aprendizaje automático en su GPU.

Las cifras

Ejecutamos una misma carga de trabajo WebGL de tres formas en un mismo Mac: Chrome en la VM de Bromure con el nuevo renderizador, Chrome en la misma VM con el dispositivo gráfico de Apple (y por tanto con llvmpipe), y Chrome en macOS.

Cada cifra es la mediana de cinco ensayos, en tiempo real transcurrido hasta terminar un lote de trabajo de GPU. Menos es mejor.

Frente al renderizado por software, la nueva vía fue 8,1x, 30,0x y 52,1x más rápida, y la diferencia creció con el trabajo por píxel. Frente a Chrome nativo, la VM tardó 1,61x, 1,41x y 1,07x lo que tardó este. Lo que más cuesta son muchas llamadas de dibujo pequeñas, y con el shader más pesado la VM quedó a un 7% del nativo.

Configuración: Bromure 5.0.1 en un Apple M5 Pro con 18 núcleos de CPU y 64 GB, con macOS 27.0.1. La VM ejecutaba Ubuntu 24.04 ARM64 con Mesa 25.2.8, 9 vCPU y 4 GB. Las tres vías usaron Chrome 154.0.8037.57. Cada muestra hace primero un calentamiento y termina con una lectura de un píxel que obliga a la GPU a terminar, así que los tiempos cubren el navegador, el driver y la lectura, y dejan fuera la compilación de shaders.

Llevar los fotogramas a la pantalla

Publicar en el flush. Un invitado con GPU Virtio nombra primero el recurso de scanout y hace el flush cuando el contenido está listo. Nuestra primera versión publicaba en el scanout y podía mostrar una superficie a medio pintar. Bromure actualiza ahora la ventana en el flush.

Una retención acotada al redimensionar. Con un tamaño nuevo, el primer fotograma suele salir casi negro o lleno de huecos, antes de que la página se vuelva a pintar. Durante un redimensionado, Bromure mantiene en pantalla el fotograma pintado anterior durante un tiempo acotado mientras el nuevo parezca sin pintar, y el host y el invitado marcan juntos el ritmo del redimensionado. La comprobación tiende a retener, así que una página oscura puede ir un instante por detrás durante un redimensionado. Fuera de un redimensionado, los fotogramas se muestran de inmediato.

En una ejecución trazada con cuatro VM, 24 pestañas y 40 visitas a sitios, cuatro grabaciones de 200 segundos no tuvieron ningún fotograma casi negro.

Alfa del cursor. Linux reserva las imágenes de cursor en un formato sin canal alfa y luego usa esa memoria como un cursor con alfa. El renderizador conserva los valores alfa que escribió el invitado, así que los cursores siguen siendo transparentes.

Contrapresión. El invitado puede enviar comandos 3D más deprisa de lo que el host los reproduce. Bromure limita cada envío a 1 MiB y reutiliza una única cola de comandos de Metal para capturar los fotogramas.

Cómo se construyó

Astra 6.1 hizo toda la implementación, ejecutándose como dos agentes en Bromure: uno en el Mac y otro en Linux. Nosotros fijamos los requisitos y probamos los resultados.

• El agente de macOS construyó el renderizador, el dispositivo Virtio, y la presentación y la entrada.
• El agente de Linux construyó el empaquetado de Mesa y VirGL, las comprobaciones de requisitos previos, y el agente de puntero y el vigilante de redimensionado de la VM.
• Pruebas de regresión y revisión de código independientes comprobaron el trabajo por el camino.

Los dos agentes trabajaron en la misma rama de funcionalidad compartida. Intercambiaron mensajes, adjuntos, peticiones y resultados de pruebas entre los dos entornos a través de la mensajería entre agentes de Bromure. El host intermedia, filtra y registra los mensajes, y copia los archivos adjuntos entre máquinas. La próxima aplicación Bromure Sidecar forma parte de este esfuerzo más amplio; la describiremos cuando salga.

Activarlo y desactivarlo

En Bromure 5, el renderizador Metal está en Rendimiento en cada perfil de Bromure Web. Viene activado por defecto, también en los perfiles existentes.

• Necesita macOS 27. En macOS 26 y anteriores, Bromure sigue renderizando por software.
• El ajuste global sigue siendo el interruptor general, y los cambios se aplican a las ventanas nuevas.
• Un perfil con el renderizador desactivado tiene su propia VM con la antigua vía gráfica.
• Una imagen de VM necesita una marca que indique que la hemos validado para el nuevo renderizador. Sin ella, Bromure vuelve al software.

Verificamos la antigua vía gráfica en macOS 27 y la probamos en un Mac con macOS 26. El nuevo código requiere macOS 27 o posterior.