mozilla Obsidian API. La propuesta de Mozilla para suceder a WebGL

[Shiba87 38,619]

 

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

[pacoeloyo 11,302]

Ojalá tomen una buena decisión, y si es mandar al infierno a java mucho mejor.

Entiendo con java mucha gente se gana la vida, pero también es cierto que java es una lacra

 

Enviado desde mi Aquaris E4 mediante Tapatalk

 

 

 

 

[erremartin 156]

hace 51 minutos, pacoeloyo dijo:

... pero también es cierto que java es una lacra ...

 

 

 

 

 

En mi modesta opinión... Java es un mojón.

 

Es cierto que sirve para casi todo, y es multi-plataforma, pero... hace las aplicaciones muy pesadas.

Y nunca se me ha dado bien la POO

[Shiba87 38,619]

Yo me he perdido. Que hablamos de APIs gráficas web de bajo nivel ¿De dónde sale java?

[pacoeloyo 11,302]

Del javascript, ¿o no tiene nada que ver?

Enviado desde mi Aquaris E4 mediante Tapatalk

[chujalt 511]

Nooo.... Java y Javascript se parecen en el nombre.

Javascript es un lenguaje interpretado y Java compilado.