HTML en Canvas: Uniendo UI y GPU en la Web

Hola a todos. Soy Santiago Colombato. Trabajo como desarrollador front-end en Basement Studio. Construimos sitios y experiencias con empresas como Brazil, Daylight, MrBeast, y mucho de lo que enviamos utiliza WebGL.

Hoy, quiero hablar sobre una brecha con la que seguimos encontrándonos, y esa brecha es hacer que el DOM y WebGL se muevan como uno solo. Cuando construyes un sitio web visualmente pesado, generalmente tienes dos fases para gestionar. Un lado, es el DOM. Te da diseño, texto, desplazamiento, accesibilidad, y el otro es WebGL, shaders, renderizado con GPU, efectos geniales, básicamente. El desafío comienza cuando ambos necesitan mantenerse sincronizados, y la parte difícil es hacer que se muevan como uno solo.

Así que, me voy a centrar en un problema específico hoy, y ese es la sincronización de desplazamiento. Pero primero, la mayoría de ustedes escribe JavaScript, pero no todos escriben WebGL, así que permítanme tomar un minuto para cubrir lo básico para que podamos entender el contexto completo. Cuando trabajas en una página web normal, escribes HTML y CSS, el navegador calcula el diseño, pinta texto y elementos, y todo funciona. No piensas mucho en la GPU.

WebGL cambia eso. WebGL es una API de JavaScript que te permite renderizar gráficos dentro de un elemento canvas. Trabajas directamente con la GPU. Pero la compensación aquí es que dejas el flujo de renderizado normal del navegador. Dentro del canvas, no tienes HTML. No tienes CSS. Así que, solo estás dibujando píxeles con pequeños programas que se ejecutan en la GPU. Esos programas se llaman shaders. Tenemos dos tipos de shaders. El primero es el vertex shader.

Ese programa se ejecuta una vez por vértice, y el trabajo es simple. Toma una posición 3D, y produce una coordenada de pantalla. Si quieres mover, escalar o transformar algo en WebGL, trabajarás con el vertex shader. El segundo es el fragment shader. Una vez que la GPU sabe dónde están los triángulos, los rellena. Así que, para cada píxel dentro de un triángulo, el fragment shader decide qué color escribir. Piensa en efectos visuales, luces, texturas. Todo eso es el fragment shader, respondiendo la misma pregunta millones de veces por cuadro. ¿De qué color debería ser este píxel?

Básicamente, el vertex shader decide dónde, y el fragment shader decide cómo se ve. Si miras sitios web visualmente pesados como este, seguro que usarán este modelo híbrido. El DOM sigue ahí, pero el canvas está haciendo gran parte del trabajo visual pesado. Los resultados pueden verse geniales, pero hay un costo. El navegador entiende el DOM, pero tu escena de WebGL es como una caja negra. Así que, necesitamos hacer que estén de acuerdo. Y el desplazamiento es donde las cosas empiezan a romperse. Cuando desplazas una página, el navegador actualiza la posición de desplazamiento visual inmediatamente. Pero tu capa de WebGL se actualiza desde JavaScript, dentro de un bucle de cuadros, desde un valor de muestra después del desplazamiento. Así que, tienes dos sistemas que están cerca en el tiempo, pero no son lo mismo.

El navegador mueve la página, y el canvas reacciona un cuadro después. Usualmente, apenas notas esto, pero no queremos eso. Así que, déjame mostrarte un caso real. Tenemos una demo aquí con una escena de WebGL que dibuja este efecto de líder sobre las imágenes. Y si desplazo, verás que la capa de WebGL se desplaza. Así que, necesitamos arreglar esto. Y lo primero que podemos hacer es fijar el canvas, y pasar el desplazamiento superior para que coincida con el desplazamiento en cada cuadro. Básicamente, estás haciendo que la posición del canvas sea absoluta, y estás actualizando el desplazamiento superior para que coincida con el desplazamiento. Esto elimina la deriva. Pero por favor revisa esto, los bordes del canvas. Se están recortando. Así que, nos estamos acercando.

Y para solucionar el recorte anterior, podemos añadir overscan. Overscan es básicamente un relleno en cada borde, píxeles extra que actúan como un buffer. La demora sigue ahí, pero ahora tiene dónde esconderse. Y el último enfoque va un nivel más profundo. Voy a hacer una demostración primero, y luego lo explico. Pero básicamente, verás que ahora el DOM y la escena de WebGL están sincronizados. Si revisas el canvas, no hay recorte, y tenemos la capa de WebGL sincronizada con el DOM. Así que, déjame explicar eso. Básicamente, lo que haces es leer la posición de desplazamiento actual, y la pasas al Vertex Shader, y aplicas ese desplazamiento a la posición de la malla. Porque recuerda, como dijimos, el Vertex Shader decide dónde van las cosas. Así que, necesitamos actualizar el Vertex Shader. La GPU lee el desplazamiento Y en el momento de dibujar, y el elemento se posiciona en el momento de renderizar. Y como vimos, el DOM y el canvas se llenan juntos. Sin deriva visual, sin recorte. Pero mira lo que construimos para llegar aquí. Overscan, pipelines de desplazamiento, tenemos que crear un Vertex Shader común para cada componente de la página. Así que, también tenemos otra característica. Tenemos redimensionamiento, zoom, enfoque, texto. Cada característica que los navegadores te dan gratis en el DOM, o la reconstruyes o la dejas ir. Así que, si tan solo pudiéramos tener elementos HTML en un canvas de WebGL, eso sería perfecto. Así que, entraremos en eso.

Pero primero, Tomas, mi compañero, va a mostrarte lo que sucede cuando intentas renderizar texto en la GPU. Gracias. Hola a todos, soy Tomas Herreras, soy desarrollador front-end en Basement Studio. Mi trabajo se sitúa en algún lugar entre el DOM y un canvas, porque construimos sitios que la mayoría de las veces se apoyan en WebGL y shaders. Y una vez que pasas suficiente tiempo en ese trabajo, empiezas a notar que todo lo que vive dentro de un canvas es esencialmente una caja negra. Para rastreadores, para lectores de pantalla, y para robots. Un campo de entrada, por ejemplo, en WebGL, es una malla en un espacio 3D con un material shader pretendiendo ser uno. Pero eso no es rastreable y no es accesible, y estamos perdiendo cada beneficio que el HTML nativo nos daba gratis. Así que, para mí, uno de los mayores puntos de dolor son las tipografías.

Porque hoy en día, renderizar fuentes en WebGL generalmente implica un pipeline similar a este. Básicamente, eliges una fuente, un formato de fuente TTF u OTF, y tienes que definir el conjunto de caracteres que deseas soportar. Luego tienes que crear el MSDF Atlas. Un MSDF Atlas es básicamente un png más un archivo JSON con destellos y métricas. Luego tienes que cargar ese Atlas y construirlos. Y finalmente, tienes que escribir un fragment shader MSDF personalizado. Luego, si quieres DPR, ajuste de texto o desbordamiento de texto, tienes que manejarlo por ti mismo. Así que el resultado es aproximadamente 150 líneas de lógica de renderización más 30 líneas de GLSL. Y los destiladores de fuentes no saben nada sobre la sintaxis CSS o accesibilidad. Si quieres texto en negrita, tienes que volver a crear la fuente. Si quieres añadir una cursiva, tienes que volver a crearla, y así sucesivamente. Tienes que volver a crear cada vez que tengas algún cambio en ese conjunto de caracteres previamente definido.

E incluso entonces, todavía estamos perdiendo selecciones de texto. Todavía estamos perdiendo la búsqueda en la página, el lector de pantalla, la sintaxis CSS para decoración, el salto de línea adecuado, entre otros. Pero, ¿cómo resolvemos esto hoy? Porque este pipeline se está volviendo realmente complejo. Y para ser justos, hay algunas formas de solucionar estos problemas. Tenemos soluciones alternativas, tenemos abstracciones, tenemos bibliotecas, que son realmente buenas, y producen un gran resultado. De hecho, las usamos en el sitio web de Basement Studio en la página de arcade. Pero cuanto más intentas acercarte al comportamiento nativo del navegador, más complejo se vuelve. Empiezas a recrear sistemas de selección, comportamientos del cursor, ajuste de texto, accesibilidad, todo eso por ti mismo. Y entonces básicamente estás reconstruyendo el navegador dentro de WebGL.

Así que, estas cosas complicadas y complejas están empezando a cambiar. Y ha comenzado a cambiar con algo llamado HTML en Canvas. HTML en Canvas es una propuesta que permite a los desarrolladores renderizar elementos HTML, botones reales, formularios reales, texto complejo real directamente dentro del canvas. Actualmente, está en fase experimental, por lo que tienes que habilitar una bandera dentro de Chrome. Pero funciona en torno a cuatro pilares. El primero es el subárbol de diseño. Es un atributo. Lo pones en el canvas y permite niños dentro de él. Básicamente, le estás diciendo al navegador, oye, no muestres estos elementos como deberías, pero mantenlos vivos y listos para que pueda dibujarlos cuando los necesite.

El segundo es la imagen del elemento de dibujo. Esta es una función de renderizado. Así que, tomas elementos HTML reales que existen dentro del canvas, y los dibujas donde quieras dentro del contexto de renderizado. Así que, estos son elementos reales, mantén tu sombreado. Así que, es realmente genial.

Luego, el tercero es el evento de pintura, un nuevo evento que se activa cada vez que el HTML subyacente cambia. Por ejemplo, si tienes un input y el usuario comienza a escribir dentro de ese input, ese evento se activa, y sabes exactamente cómo redibujarlo y mantener las cosas sincronizadas.

Y el último es la captura de imagen del elemento. Básicamente, toma una instantánea de un elemento, para que puedas transferirlo a un trabajador. Esto es útil si estás trabajando con canvases fuera de pantalla. Estas son cuatro piezas, un atributo, dos métodos y un evento. Esa es toda la propuesta. Así que, probablemente estés pensando ahora mismo, bien, entonces, ¿qué desbloquea esta propuesta para los desarrolladores? Y básicamente, una vez que apilas todas las cuatro piezas juntas, las cosas de repente se vuelven posibles, y tienes posibilidades ilimitadas, y eso es bastante salvaje. Básicamente, puedes tener texto complejo, ajuste, interactividad, accesibilidad, tienes efectos visuales, puedes aplicar WebGL, shaders, post-procesamiento, o lo que sea, a elementos DOM reales como un div o un formulario. Y luego puedes sombrearlo con cualquier shader, cualquier post-procesamiento que te guste. Tenemos un ejemplo con un efecto CTR que es bastante bueno. Así que, entonces podemos mostrarte eso.

Y para la sincronización de desplazamiento, hablando de la sincronización de desplazamiento, el problema es que Santi pasa la mitad de la charla simplemente desapareciendo. Básicamente, el navegador dibuja todos los elementos del DOM como un hijo del canvas. Envuelves todo el sitio web con un canvas, así que no hay más retrasos ni cosas complicadas. Ahora mismo, es la primera vez que tenemos la GPU y el modelo de documento como uno solo. No hay puentes, ni copias, ni cosas raras en soluciones alternativas. Simplemente sincroniza el HTML y las cosas de WebGL.

Lo que dibujas dentro del navegador ya entiende que está dentro de un canvas o algo así. Así que básicamente, ahora mismo, tenemos dos ejemplos que están relacionados con WebXR. Como soy desarrollador de WebXR, de hecho pasé mucho tiempo haciéndolo. Pero lo que estás viendo aquí son dos demos. Estos son HTML real en un espacio 3D. El primero es que jugué mucho a los juegos de Fallout, así que decidí hacer un BitBoy dentro de WebXR. Esto es realmente complejo con las soluciones actuales debido al diseño complejo, pero aquí solo está usando HTML y CSS, así que es realmente simple hacerlo.

Y luego el segundo es otro experimento que hicimos en WebXR. Estamos usando nuestras manos para destruir un mundo basado en física. El mundo está conteniendo la sección de oradores de JS Nation. Todo esto es WebGL y HTML, pero no hay soluciones alternativas. Es el DOM simple dentro de un canvas. Esta es la parte que más me emociona, porque siempre había una concesión, o solía haber una concesión, de si quieres que se vea hermoso o si quieres hacerlo accesible y rastreable. Ahora mismo, con HTML en canvas, es la primera vez que realmente no tenemos que elegir.