Rendimiento de WebGL
WebGL tiene mala reputación: los desarrolladores asumen que WebGL es lento e incapaz de renderizar gráficos 3D complejos. Muchos ejemplos muestran que esto no es cierto, sin embargo, la experiencia de los desarrolladores refuerza esta idea una y otra vez.
El hardware que ejecuta el código WebGL no está limitado para los navegadores. Entonces, ¿por qué los desarrolladores creen que es imposible renderizar gráficos 3D rápidos en la web?
Este artículo lo guiará a través del rendimiento de WebGL y cómo usted también puede lograr un renderizado 3D rápido en la web.
CPU vs GPU
En una aplicación 3D, parte del código se ejecuta en la CPU y otra parte en hardware acelerado, el GPU.
WebGL está diseñado para permitir el uso del GPU para acelerar aplicaciones gráficas en la web. Por lo tanto, WebGL puede entenderse como funciones que envían trabajo al hardware gráfico y recuperan el resultado.
El código que crea el trabajo para el GPU se ejecuta en la CPU y para WebGL lo controlamos a través de JavaScript.
Sobrecarga del Navegador
Debido a que un objetivo del navegador es mantener al usuario seguro de posibles sitios web maliciosos, verificará la seguridad de cada llamada a WebGL que haga el sitio web a través de JavaScript. También necesita aislar el proceso que ejecuta el código del sitio web y cualquier llamada a y desde este proceso necesita convertirse en un formato que se pueda enviar, lo que se llama “unificación”.
Tanto la unificación como la verificación de las llamadas a WebGL del sitio web implican trabajo que agrega un costo de rendimiento, en comparación con la misma llamada en un entorno nativo.
Evitar Llamadas a WebGL
Para lograr el rendimiento de WebGL, por lo tanto, debemos evitar usar llamadas que tengan una alta sobrecarga. Descubrirá fácilmente cuáles llamadas son especialmente costosas al perfilar su aplicación de WebGL.
Las siguientes son algunas de las llamadas que son costosas de manera contraintuitiva:
Una excelente manera de evitar estas llamadas es realizar el seguimiento del estado de WebGL y reducir la comprobación de errores en las compilaciones de producción de su aplicación WebGL.
Evitar Llamadas a Dibujo
El secreto para un excelente rendimiento de WebGL, sin embargo, es tener la menor cantidad de llamadas a dibujo posible. Una llamada a dibujo es cualquier función que usa una de las siguientes funciones de WebGL:
- drawArrays()
- drawElements()
- drawArraysInstanced()
- drawElementsInstanced()
- drawBuffers()
- drawRangeElements()
Hay muchas maneras de hacerlo. Al usar una llamada de función que dibuja muchos objetos, en lugar de llamar a una función muchas veces para dibujar los mismos objetos, por ejemplo. Puede usar instancing para renderizar una gran cantidad del mismo mesh, o el WEBGL_multi_draw para renderizar muchos objetos diferentes con el mismo shader.
Los motores 3D a menudo tienen una función llamada “batching”, que fusionará muchas llamadas en una sola llamada a WebGL. Wonderland Engine lleva esto a un nivel extremo, donde escenas con decenas de miles de objetos dinámicos se renderizan en menos de diez llamadas a dibujo automáticamente.
El rendimiento de WebGL en dispositivos móviles se ve especialmente afectado por las llamadas a dibujo.
WebGL en Safari
En Safari (tanto iOS como MacOS), hay llamadas a WebGL adicionales que vienen con cantidades sorprendentemente grandes de sobrecarga, por ejemplo:
Preste especial atención al uso de Uniform Buffers al optimizar para Safari.
JavaScript
El lenguaje utilizado para interactuar con las APIs de navegación, como WebGL, es JavaScript. El principal culpable del rendimiento con JavaScript es la Recolección de Basura, que encontrará y eliminará automáticamente la memoria que ya no es necesaria.
El proceso de Recolección de Basura puede hacer que el rendimiento de la aplicación WebGL sea impredecible y poco fiable, ya que no tiene control sobre cuándo ocurrirá. Como resultado, a menudo ocurrirá en momentos cuando puede causar tartamudeo en el renderizado, dando la apariencia de un mal rendimiento, incluso cuando el código está bien optimizado.
Para producir tasas de frames estables, adopte un enfoque estricto para escribir JavaScript sin basura.
iOS Safari y Memoria
Las aplicaciones WebGL que funcionan bien en Safari son raras. El rendimiento de WebGL en Safari presenta algunos desafíos adicionales. Escribimos una publicación de blog completa sobre cómo optimizar para Safari.
Límites de Memoria
En iOS, se enfrenta a otro desafío: las pestañas del navegador tienen memoria muy limitada, especialmente en hardware de iPhone más antiguo. Si excede los límites de memoria, la pestaña puede recargarse o congelarse. Debido a que los iPhones usan memoria unificada, la RAM para CPU y GPU se comparte, y tanto los datos de texturas como de buffers, así como la memoria de JavaScript o WebAssembly, contarán hacia el límite.