Buscar en La Comunidad

Tras la llegada de Vulkan, el grupo Khronos ha empezado a remover los ciemientos del resto de APIs y WebGL no iba a quedarse atrás en el proceso de "modernización". El período de propuestas se ha abierto para definir lo que será el sucesor de WebGL, apodado de momento WebGL-Next, y como era de esperar, Mozilla no ha tardado en aportar su granito de arena con una API para renderizado de gráficos para la web de bajo nivel que sigue las premisas que dieron origen a Vulkan y a la que han llamado Obsidian. Esta API viene de la mano de WebAssembly, el estandar del que ya hablamos durante el lanzamiento de Firefox 52. Este estándar, así como la API, apuntan al uso de GPUs modernas y sistemas multi-hilo y tienen como objetivo permitir un rendimiento nativo, o prácticamente nativo, para juegos y aplicaciones 3D en el navegador sin necesidad de plugins de terceros. Desde Mozilla son conscientes que el rediseño de las APIs gráficas para la web es un paso claramente necesario y, si bien en discusiones previas se han dos posturas opuestas, una más próxima a Metal, con un enfoque de simplicidad y un nivel mas alto de abstracción y otra virtualmente opuesta, apostando por el enfoque Vulkan, un rediseño de más bajo nivel, que requiere más trabajo pero también supone una visión de gráficos más ricos en la web apoyados en una API explícita de bajo nivel, así como portable, no consideran la primera opción la más adecuada. Esta decisión no ha sido tomada a la ligera, ya que Mozilla ha puesto en práctica las dos visiones bajo su nuevo motor de renderizado servo y la aproximación con enfoque Metal en WebIDL (para Javascript) presentaba problemas de comunicación, debido precisamente a las capas de abstracción y la transcodificación de comandos entre APIs. Si bien pudieron demostrar que era una alternativa "viable", también dejaron claro que se puede aspirar a muchísimo más y si hay que rediseñar una nueva API no es cuetión de quedarse a las puertas de lo que "podría ser", sino de aprovechar la oportunidad única que se presenta y hacerlo bien desde el principio. La propuesta es clara y ya podemos encontrar en github algunos códigos de ejemplo javascript, aunque la resolución final llegará, como siempre, a partir del consenso al que lleguen los miembros del grupo Khronos. https://github.com/KhronosGroup/WebGLNext-Proposals/pull/2/commits/464c70a7ed96d323c77595d792cfc41b69955429