You are here

Mozilla Hispano

CSS Shapes, clipping y masking – y cómo usarlos

Noticias de Mozilla Hispano - 12 horas 53 mins ago

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

El lanzamiento de Firefox 54 introdujo nuevas características dentro de una propiedad ya genial de CSS: clip-path.

clip-path es una propiedad que nos permite recortar partes de un elemento. Hasta ahora, en Firefox solo podías utilizar un SVG para cortar un elemento. Pero con Firefox 54, también podrás utilizar CSS shapes: ¡Recuadros, círculos, elipses y polígonos!

Nota: esta publicación contiene muchas demostraciones que requieren soporte para clip-path y mask. Para poder ver e interactuar con cada demostración en esta publicación, vas a necesitar Firefox 54 o superior.

Uso básico

Es importante tener en cuenta que clipPath no acepta “imágenes” como entrada pero como elementos <clipPath>:

Algo genial es que estos elementos <clipPath> pueden contener animaciones SVG:

Sin embargo, con Firefox también tendremos funciones CSS shape a nuestra disposición. Éstas nos permiten definir shapes dentro de nuestras hojas de estilo, así no hay necesidad de un SVG. Las funciones shape que tenemos a nuestra disposición son: circle, ellipse, inset y polygon. Aquí los puedes ver en acción:

Y no sólo eso, también podemos animarlos con CSS. Las únicas restricciones son de que no podemos “mezclar” las funciones shapes (por ejemplo, mutar de un circle a un inset) y con polígonos animados, los polígonos deben preservar el mismo número de vértices durante toda la animación.

Aquí hay una animación simple utilizando un shape de circle:

Y aquí hay otra animación que utiliza polygon. Nota: aunque estemos limitados a preservar nuestro número de vértices, los podemos “mezclar” repitiendo los valores. Esto crea la ilusión de animar al polígono con cualquier número de lados.

Nota que el clip-path también abre nuevas posibilidades de diseño. La siguiente demostración utiliza clippping para hacer una imagen más interesante en un artículo de varias columnas:

Animando cosas con JavaScript

Clipping abre buenas posibilidades. En el siguiente ejemplo, clip-path ha sido utilizado para aislar elementos de un sitio. En este caso, simulando un tour/tutorial:

Se hace con JavaScript obteniendo las dimensiones de un elemento durante el proceso, y calculando la distancia respecto a un contenedor de referencia, y luego utilizando esa distancia para actualizar la forma de recuadro utilizada en la propiedad clip-path.

Ahora también podemos cambiar dinámicamente el clipping de acuerdo a la entrada del usuario, como en este ejemplo que incluye un efecto “periscopio” controlado por el mouse:

¿clip-path o mask?

Existe una propiedad CSS similar, mask, pero no es idéntica a clip-path. Dependiendo de tu caso de uso específico, deberías elegir una u otra. También nota que el soporte varía entre los navegadores, y actualmente Firefox es el único navegador que soporta completamente todas las características de mask, así que vas a necesitar ejecutar Firefox 54 para interactuar con las demostraciones de abajo en Codepen.

Masking puede utilizar una imagen o un elemento <mask> en un SVG. Por otro lado, clip-path utiliza un path SVG o un shape CSS.

Masking modifica la apariencia del elemento que oculta. Por ejemplo, aquí hay un mask circular llenado con un gradiente lineal:

Y recuerda que también puedes utilizar imágenes bitmap aún si no tienen un canal alfa (transparencia), mediante la modificación del mask-mode:

El concepto clave de masking es que modifica los píxeles de una imagen, cambiando sus valores  hasta el punto de hacer de algunos de ellos completamente transparentes.

Por otro lado, clipping “corta” el elemento, y esto incluye su superficie de colisión. Mira la siguiente demostración que muestra dos imágenes idénticas con mask y clip con la misma forma de cruz. Intenta posar el cursor sobre las imágenes y ve lo que pasa. Notarás que en la imagen con mask el área de colisión también contiene partes con mask. En la imagen clipped, la única parte visible es el área de colisión (la forma de cruz) del elemento.

¿Entonces masking es mejor que clipping, o viceversa? No, solo son utilizadas para diferentes cosas.

Espero que esta publicación haya despertado tu curiosidad sobre clip-path. ¡Utiliza Firefox para probarla!

Artículos relacionados:

Categorías: Mozilla Hispano

Quantum de cerca: ¿qué es el motor de un navegador web?

Noticias de Mozilla Hispano - Dom, 12/11/2017 - 03:16

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Sergio Carlavilla Delgado.

En octubre del año pasado Mozilla anunció el Proyecto Quantum – nuestra iniciativa para crear un motor de navegación web de nueva generación. Ya estamos en marcha con el proyecto. De hecho liberamos nuestra primera pieza significativa de Quantum con Firefox 53.

Pero sabemos que para personas que no construyen navegadores web (¡y eso es la mayoría de la gente!), puede ser difícil ver por qué algunos de los cambios que estamos realizando en Firefox son tan importantes. Después de todo, muchos de los cambios que estamos haciendo serán invisibles para los usuarios.

Con esto en mente, estamos lanzando una serie de publicaciones para proporcionar una visión más profunda de lo que estamos haciendo con el proyecto Quantum. Esperamos que esta serie de publicaciones te brinde una mejor comprensión de cómo funciona Firefox y las formas en que Firefox está construyendo un motor de navegación web de nueva generación para mejor aprovechar el hardware de los ordenadores modernos.

Para comenzar esta serie de publicaciones, creemos que es mejor comenzar por explicar el aspecto fundamental que Quantum está cambiando.

¿Qué es un motor de navegación web y cómo funciona?

Si vamos a empezar por algún lado, debemos empezar desde el principio.

Un navegador web es una pieza de software que carga archivos (normalmente de un servidor remoto) y los muestra localmente, permitiendo la interacción del usuario.

Quantum es el nombre clave para un proyecto que hemos emprendido en Mozilla para actualizar masivamente la parte de Firefox que calcula qué mostrar a los usuarios basándose en esos archivos remotos. El término que utiliza la industria para esta parte es “motor web”, y sin uno, estarías leyendo código fuente en lugar de ver realmente un sitio web. El motor web de Firefox se llama Gecko.

Es bastante fácil ver al motor web como una caja negra, algo así como una TV: los datos entran, y la caja negra calcula qué mostrar en la pantalla para representar esos datos. La pregunta de hoy es: ¿cómo? ¿Cuáles son los pasos que convierten los datos en las páginas web que vemos?

Los datos que componen una página web son muchas cosas, pero se desglosan principalmente en 3 partes:

  • código que representa la estructura de una página web
  • código que proporciona estilo: el aspecto visual de la estructura
  • código que actúa como un script de acciones que el navegador puede tomar: computación, reaccionar a las acciones del usuario, y modificar la estructura y el estilo más allá de lo que se cargó inicialmente.

El motor del navegador web combina la estructura y el estilo para dibujar la página web en tu pantalla y averiguar qué partes son interactivas.

Todo comienza con la estructura. Cuando se le pide a un navegador web que cargue un sitio web, se le da una dirección. En esta dirección se encuentra otra computadora que, cuando es contactada, enviará los datos de vuelta al navegador web. Los detalles de cómo esto ocurre es un artículo completo en sí mismo, pero al final el navegador tiene los datos. Estos datos son enviados en un formato denominado HTML, y este describe la estructura de la página web. ¿Cómo entiende un navegador web HTML?

El motor del navegador web contiene fragmentos especiales de código llamados parsers que convierten los datos de un formato en otro que el navegador web mantiene en su memoria. El parser de HTML toma el HTML, algo así como:

Hello!

Y lo analiza, entendiendo:

Bien, hay una sección. Dentro de la sección se encuentra un título de nivel 1, que contiene el texto: “Hello!”. También hay una imagen dentro de la sección. Puedo encontrar los datos de la imagen en la ubicación: http:// example.com/image.png

La estructura almacenada en memoria de la página web se denomina Modelo de Objeto de Documento o DOM (Document Object Model). A diferencia de un texto largo, el DOM representa un árbol de elementos de la página web final: las propiedades de los elementos individuales y qué elementos están dentro de otros elementos.

Además de describir la estructura de la página, el HTML también incluye direcciones donde se pueden encontrar estilos y scripts. Cuando el navegador los encuentra, se pone en contacto con esas direcciones y carga sus datos. Esos datos alimentan a otros parsers que están especializados en esos tipos de datos. Si se encuentran scripts, pueden modificar la estructura y el estilo de la página antes de que haya finalizado el parseo del archivo. El formato de estilo, CSS, juega el siguiente papel en nuestro motor del navegador web.

Con estilo

CSS es un lenguaje de programación que permite a los desarrolladores describir la apariencia de elementos particulares en una página. CSS significa “hojas de estilo en cascada”, denominado así porque permite múltiples conjuntos de instrucciones de estilo, donde las instrucciones pueden sobreescribir las instrucciones anteriores o más generales (llamado cascada). Un poco de CSS podría tener el siguiente aspecto:

section { font-size: 15px; color: #333; border: 1px solid blue; } h1 { font-size: 2em; } .main-title { font-size: 3em; } img { width: 100%; }

CSS se divide en gran parte en agrupaciones llamadas reglas, que constan de dos partes. La primera parte son los selectores. Los selectores describen los elementos del DOM (¿recuerdas los de arriba?) a los que se les está aplicando los estilos y una lista de declaraciones que especifican los estilos que se aplicarán a los elementos que coincidan con el selector. El motor del navegador web contiene un subsistema llamado motor de estilos cuyo trabajo es tomar el código CSS y aplicarlo al DOM que fue creado por el parser HTML.

Por ejemplo, en el CSS anterior, tenemos una regla que hace referencia al selector “section”, que coincidirá con cualquier elemento en el DOM con ese nombre. Entonces se hacen anotaciones de estilo para cada elemento en el DOM. Eventualmente, cada elemento en el DOM termina teniendo un estilo y llamamos a este estado el estilo computado para ese elemento. Cuando se aplican múltiples estilos que compiten sobre el mismo elemento, los que vienen después o son más específicos ganan. Piensa en las hojas de estilo como en el papel de trazado fino; cada capa puede cubrir las capas anteriores, pero también permite que se muestren las capas inferiores.

Una vez el motor del navegador web ha computado los estilos, ¡es hora de ponerlo en uso! El DOM y los estilos computados son introducidos en un motor de diseño que tiene en cuenta el tamaño de la ventana que se est´ dibujando. El motor de diseño utiliza varios algoritmos para tomar cada elemento y dibujar una caja que incluya su contenido y tenga en cuenta todos los estilos que se le aplican.

Cuando el diseño esta completo, es el momento de convertir el esquema de la página en la parte que tú ves. Este proceso se conoce como dibujado, y es la combinación final de todos los pasos previos. Cada caja definida se dibuja, llena del contenido del DOM y con los estilos del CSS. Ahora el usuario ve la página, reconstruida a partir del código que la define.

¡Esto solía ser todo lo que sucedía!

Cuando el usuario desplaza la página, volveremos a dibujar, para mostrar las partes nuevas de la página que estaban anteriormente fuera de la ventana. ¡Resulta, sin embargo, que a los usuarios les encanta desplazar la página! El motor del navegador web sabe con bastante seguridad que se le pedirá que muestre contenido fuera de la ventana inicial que ha dibujado (llamada ventana de visualización o viewport). Los navegadores más modernos aprovechan este hecho y dibujan más página de la que está visible inicialmente. Cuando el usuario se desplaza, las partes de la página que quiere ver ya están dibujadas y listas. Como resultado, el desplazamiento es más rápido y fluido. Esta técnica es la base de la composición, que es un término para las técnicas que reducen la cantidad de pintados requeridos.

Además, algunas veces necesitamos volver a dibujar partes de la pantalla. Tal vez el usuario esté viendo un vídeo que se reproduce a 60 cuadros por segundo. O tal vez hay una presentación de diapositivas o una lista animada en la página. Los navegadores pueden detectar qué partes de la página se moverán o actualizarán, y en lugar de pintar toda la página, crean una capa para contenerlo. Una página puede estar formada por muchas capas que se superponen entre sí. Una capa puede cambiar de posición, desplazamiento, transparencia o moverse detrás o delante de otras capas, ¡sin tener que volver a pintar nada! Bastante conveniente.

A veces, un script o una animación cambia el estilo de un elemento. Cuando esto ocurre, el motor de estilo necesita volver a calcular el estilo del elemento (y potencialmente el estilo de muchos más elementos de la página), recalcular el diseño y volver a dibujar la página. Esto lleva mucho tiempo en términos de velocidad de computadora, pero siempre que ocurra de manera ocasional, el proceso no afectará negativamente la experiencia del usuario.

En las aplicaciones web modernas, la estructura del documento en sí misma es modificada frecuentemente por los scripts. Esto podría requerir que todo el proceso de diseño comience más o menos desde cero, con el HTML siendo analizado en el DOM, computar el estilo, reflujo y dibujado.

Estándares

No todos los navegadores web interpretan HTML, CSS y JavaScript de la misma forma. El efecto puede variar: desde pequeñas diferencias visuales hasta el sitio web ocasional que funciona en una navegador y en no en otro. Actualmente, en la Web moderna, la mayoría de los sitios web parecen funcionar independientemente del navegador que elija. ¿Cómo logran los navegadores este nivel de consistencia?

Los formatos del código de sitios web, así como las reglas que rigen la forma en que el código se interpreta y se convierte en una página visual interactiva, se definen mediante documentos mutuamente acordados denominados estándares. Estos documentos son desarrollados por comités que constan de representantes de los fabricantes de los navegadores web, desarrolladores web, diseñadores y otros miembros de la industria. Juntos determinan el comportamiento preciso que el motor del navegador web debería exhibir dada una pieza especifica de código. Existen estándares para HTML, CSS y JavaScript, así como los formatos de datos de imágenes, vídeo, audio y más.

¿Por qué es esto importante? Es posible crear un motor para el navegador web completamente nuevo, y siempre que se asegure de que el motor cumpla los estándares, dibujará las páginas web de una manera que coincida con el resto de navegadores web, para las miles de millones de páginas web. Esto significa que la “salsa secreta” para hacer que los sitios web funcionen no es un secreto perteneciente a un navegador. Los estándares permiten a los usuarios elegir el navegador web que satisfaga sus necesidades.

No más ley de Moore

Cuando los dinosaurios vagaban por la tierra y las personas solo tenían ordenadores de escritorio, era una suposición relativamente segura de que las computadoras se volverían más rápidas y potentes. Esta idea se baso en la Ley de Moore, una observación en la cual la cantidad de componentes (y por lo tanto la miniaturización / eficiencia de los chips de silicio) se duplicaría aproximadamente cada dos años. Increíblemente, esta observación fue válida hasta bien entrado el siglo XXI, y algunos argumentarán que sigue siendo válida en la vanguardia de la investigación actual. Entonces, ¿por qué la velocidad de un ordenador medio parece haberse estabilizado en los últimos 10 años?

La velocidad no es la única característica que los clientes buscan cuando compran un ordenador. Los ordenadores rápidos suelen consumir mucha energía, calentarse mucho y ser muy costosos. A veces, la gente quiere un ordenador portátil que tenga una buena duración de la batería. A veces, quieren un pequeño ordenador con pantalla táctil, con una cámara que quepa en el bolsillo y ¡que dure todo el día sin cargar! Los avances en informática lo han hecho posible (¡lo cual es increíble!), pero a costa de la velocidad bruta. Del mismo modo que no es eficiente (ni seguro) conducir tu coche lo más rápido posible, no es eficiente conducir tu ordenador lo más rápido posible. La solución ha sido tener múltiples “ordenadores” (núcleos) en un chip de CPU. No es raro ver teléfonos inteligentes con 4 núcleos más pequeños y menos potentes.

Lamentablemente, el diseño histórico del navegador web asumió esta trayectoria ascendente de velocidad. Además, escribir código que sea bueno usando múltiples núcleos de la CPU al mismo tiempo puede ser extremadamente complicado. Entonces, ¿cómo hacemos un navegador rápido y eficiente en la era de muchos ordenadores pequeños?

¡Tenemos algunas ideas!

En los próximos meses, analizaremos más detenidamente algunos de los cambios que llegarán a Firefox y cómo aprovecharán mejor el hardware moderno para ofrecer un navegador más rápido y estable que haga brillar los sitios web.

¡Adelante!

Artículos relacionados:

Categorías: Mozilla Hispano

El monitor de red recargado (parte 1)

Noticias de Mozilla Hispano - Sáb, 14/10/2017 - 00:01

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Sergio Carlavilla Delgado.

La herramienta del monitor de red ha estado disponible en Firefox desde los primeros días de las herramientas de desarrollo de Firefox. Es una herramienta indispensable para cualquier persona que se preocupa por el rendimiento de carga de las páginas web y las páginas web modernas y rápidas. Esta herramienta pasó por una extensa refactorización recientemente (bajo el nombre Netmonitor.html) y este artículo pretende ser una explicación de cómo diseñamos la nueva arquitectura y qué nuevas tecnologías hemos utilizado.

Observa el monitor de red ejecutándose dentro de la caja de herramientas de desarrollador de Firefox:

Objetivos

Uno de los principales objetivos de la refactorización fue reconstruir toda la herramienta utilizando tecnologías web estándar. Hemos eliminado todo el código antiguo específico de Firefox como XUL (XML User Interface Language), pero también el código que utilizaba APIs específicas de Firefox. Este es un gran paso adelante, ya que utilizar estándares web ahora te permite ejecutar todo el código en dos entornos diferentes:

  • Caja de herramientas de desarrollo
  • Cualquier página web

El primer caso es bien conocido para cualquiera que este familiarizado con las herramientas de desarrollo de Firefox (también puedes ver la imagen anterior). La caja de herramientas de desarrollo puede ser abierta fácilmente en la parte inferior de la ventana del navegador con varias herramientas, monitor de red incluido, a tu alcance.

El segundo caso de uso es nuevo. Ahora la herramienta puede cargarse dentro de una pestaña del navegador como cualquier otra aplicación web estándar. Observa cómo se ve en la siguiente captura de pantalla:

Nota que la página se carga desde localhost:8000. Ahí es donde se está ejecutando el servidor de desarrollo.

¡La posibilidad de ejecutar la herramienta como una aplicación web es una gran oportunidad! Ahora podemos utilizar todas las herramientas del navegador para el trabajo de desarrollo. Aunque antes era posible usar las herramientas de desarrollo para depurar las herramientas de desarrollo (con la caja de herramientas del navegador), ahora es mucho más fácil y más conveniente simplemente el uso de las herramientas del navegador. Y por supuesto, podemos ejecutar la herramienta en otros navegadores. El desarrollo también es más simple ya que no tenemos que compilar Firefox. En su lugar, una simple recarga de la pestaña es suficiente para volver a cargar el monitor de red y probar tus cambios en el código.

Arquitectura

Hemos construido el front-end del nuevo monitor de red sobre las siguientes tecnologías:

Las herramientas de desarrollo de Firefox necesitan funciones complejas para la interfaz gráfica y estamos usando el popular combo React & Redux para todas nuestras herramientas para construir un código limpio y consistente. El monitor de red no es una excepción. Hemos implementado un conjunto de componentes de React los cuales son responsables de procesar la vista (interfaz), un almacén con todos los datos interceptados por HTTP y finalmente un conjunto de acciones que el usuario podría querer ejecutar.

También hemos cambiado la forma en la que escribimos las pruebas. En lugar de utilizar la infraestructura de pruebas específica de Firefox, estamos cambiando lentamente hacia bibliotecas bien conocidas como Mocha y Enzyme. De esta manera es más fácil entender nuestro código y también contribuir a él.

Estamos utilizando Webpack para crear un paquete cuando se ejecuta dentro de una página web. Por consiguiente el paquete es servido a través de localhost:8000.

La arquitectura general está basada en un flujo introducido en el concepto React & Redux.

  • El componente raíz que representa el NetMonitorApp puede ser renderizado dentro de la caja de herramientas o en una página web.
  • Las acciones son responsables de cosas como el filtrado, limpieza de la lista de peticiones, ordenamiento y apertura de un panel lateral con información detallada.
  • Todos nuestros datos son almacenados dentro del objeto de almacenamiento. Incluyendo todos los datos recopilados sobre el tráfico HTTP.
Nuevas características

Hemos estado centramos principalmente en la refactorización del código, pero también se han implementado algunas nuevas características / mejoras en la interfaz de usuario a lo largo del camino. Veamos algunas de ellas.

Selector de columna

Hay nuevas columnas con información adicional sobre las solicitudes individuales y el usuario puede usar el menú contextual para seleccionar las que son importantes.

Resumen de datos

Hemos implementado un mejor resumen de las solicitudes mostradas actualmente en la lista. Ahora se encuentran en la parte inferior del panel.

  • Número de peticiones en la lista
  • Tamaño / tamaño transferido de todas las peticiones
  • Tiempo total requerido para cargar todas las peticiones
  • Tiempo en que el evento DomContentLoaded
  • Tiempo en que el evento load ocurre
Filtrado por propiedades

La interfaz de usuario del filtrado es ahora mucho más potente. Es posible filtrar la lista de peticiones conforme a varias propiedades. Por ejemplo, puedes escribir: larger-than:50 en la caja de entrada del filtro para ver sólo aquellas peticiones que son mayores de 50 bytes.

Lee más sobre el filtrado por propiedades en MDN.

Aprende más en MDN

Hay enlaces en muchos lugares de la interfaz de usuario que llevan a MDN para obtener más información. Por ejemplo, puedes aprender rápidamente cómo se utilizan varias cabeceras de HTTP.

Conclusión

Creemos que construir la nueva generación de herramientas para desarrolladores de Firefox utilizando estándares web es el camino correcto, ya que significa que las herramientas pueden ejecutarse en diferentes entornos e integrarse de manera más eficaz con otros proyectos (por ejemplo, IDEs). Basarse en estándares web hace muchas cosas posibles: ahora también podemos pensar en empaquetar nuestras herramientas como un servicio web que pueda beneficiarse de la plataforma de Internet. Podemos compartir datos recopilados, así como el contexto de depuración a través de la web, abriendo así las puertas a un verdadero mundo de depuración social.

El equipo de Netmonitor.html ha hecho una gran cantidad de trabajo en la refactorización. Muchas gracias al equipo principal:

  • Ricky Chien
  • Fred Lin

Pero también ha habido muchos contribuyentes externos:

  • Jaroslav Snajdr
  • Leonardo Couto
  • Tim Nguyen
  • Deepjyoti Mondal
  • Locke Chen
  • Michael Brennan
  • Ruturaj Vartak
  • Vangelis Katsikaros
  • Adrien Enault
  • Y muchos más…

Haznos saber lo que piensas. Puedes unirte a nosotros en el canal de Slack devtools-html.

Artículos relacionados:

Categorías: Mozilla Hispano

WebGL 2 disponible en Firefox

Noticias de Mozilla Hispano - Dom, 08/10/2017 - 21:39

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Sergio Carlavilla Delgado.

Con el lanzamiento de Firefox 51, ¡el soporte de WebGL2 ha llegado! WebGL es una API estándar para representar gráficos 3D en la web. Está basado en OpenGL ES, que es utilizado comúnmente para los videojuegos móviles.

Hasta la fecha, hemos sido capaces de utilizar WebGL 1 (basado en OpenGL ES 2) para representar gráficos fantásticos en el elemento <canvas>. WebGL 2, sin embargo, está basado en la especificación OpenGL ES 3.0, la cual introduce nuevas características – la mayoría destinadas a aumentar el rendimiento y la fidelidad visual.

Anteriormente, WebGL2 había sido utilizable mediante un parámetro de configuración
o en las ediciones Developer Edition o Nightly, pero con Firefox 51, está desbloqueado para todos los usuarios de Firefox en Windows, MacOS y GNU/Linux.

Demostración: “After the Flood” (PlayCanvas)

Para darte una idea del contenido que permite WebGL 2, estamos emocionados en destacar After the Flood, una demostración interactiva de WebGL 2 por PlayCanvas. (Por favor, ten en cuenta que esta demostración se encuentra disponible únicamente para el escritorio, con el soporte para móvil próximamente.) Da un paseo a través del fantástico entorno de agua, vidrio y acero ¡el cual se desarrolla completamente dentro de tu navegador web!

Cómo usar WebGL 2

Para disponer de un contexto WebGL 2, todo lo que tienes que hacer es solicitar uno a un elemento <canvas>. La cadena que usaremos para solicitar WebGL2 es “webgl2”.

let canvas = document.querySelector('canvas'); let ctx = canvas.getContext('webgl2');

WebGL 2 podría no estar presente en todos los navegadores, por lo que debes incluir algo de código para controlar los errores.

let canvas = document.querySelector('canvas'); let ctx = canvas.getContext('webgl2'); let isWebGL2 = !!ctx; if (!isWebGL2) { // intentar usar webgl 1 ctx = canvas.getContext('webgl') || canvas.getContext('experimental-webgl'); } if (!ctx) { console.log('your browser does not support WebGL'); } Unas palabras de advertencia…

Ten en cuenta que mientras WebGL 2 está basado en OpenGL ES 3.0, no es idéntico. Por ejemplo, WebGL 2 no soporta programas binarios y un número de restricciones opcionales en OpenGL se han hecho obligatorias para WebGL 2. Las diferencias entre las dos están presentadas en la especificación de WebGL 2, así que si ya estás familiarizado con OpenGL, podrás ponerte al día con WebGL 2 rápidamente.

Otra cosa a tener en cuenta es que WebGL 2 no es estrictamente compatible con WebGL1, asá que existe la posibilidad de que tu código WebGL 1 no funcione como se espera en un contexto de WebGL 2. Dicho esto, las diferencias son bastante mínimas, y deberías de poder portar tu código y shaders (sombreadores) sin mucha dificultad. Puedes leer la lista de incompatibilidades en la especificación, además de esta guía rápida de los fundamentos de WebGL 2 acerca de la migración de código desde WebGL 1 a WebGL 2.

Ten en cuenta que mientras WebGL 2 traerá estas nuevas características a muchos de nuestros usuarios, no podemos ofrecer WebGL 2 a usuarios con tarjetas gráficas o controladores viejos o anticuados.

Funciones destacadas Lenguaje de sombreado actualizado

WebGL 2 soporta OpenGL ES Shading Language 3.0, el cual permite programas de sombreado mucho más capaces y eficientes. Los nuevos juguetes incluyen:

  • Verdaderos tipos enteros
  • Bloques uniformes
  • Vincular los índices de ubicación para las entradas y salidas de shader en la fuente de sombreado
  • Descarte de fragmentos
  • Bucles dinámicos
  • Muestras sofisticadas de texturas incorporadas
Múltiples objetivos de renderizado (“MRTs”)

Este te permite renderizar varios búferes de color o texturas en un solo paso, usando múltiples salidas del sombreador de fragmentos.

Esta característica se habilitó en WebGL 1 a través de una extensión, pero ahora forma parte del conjunto básico de características de WebGL 2, por lo que no es necesario preocuparse por un camino alternativo.

Una de las principales aplicaciones de MRTs es una técnica llamada sombreado diferido – y ya hemos escrito antes acerca de ella en Hacks. Es una técnica de renderizado que permite gran cantidad de luces dinámicas en una escena, ya que la complejidad del renderizado no depende de la cantidad de luces, sino del número real de píxeles que se están encendiendo.

Dibujo de geometría instanciada

El instanciamiento te permite renderizar múltiples instancias de una geometría con una única llamada, lo que reduce la carga en la CPU. Ten en cuenta que cada instancia puede tener sus propios atributos, como una matriz de transformación, así que puedes usarlo para renderizar muchos objetos simulares, como partículas, árboles en un bosque, gente en una multitud, etc.

La siguiente demostración de THREE.js hace instanciación a través de una extensión – que, recuerda, ya no es necesaria en WebGL 2.

Nuevas características en texturas

Las texturas 3D o con volumen son texturas en las que se accede a los datos utilizando tres coordenadas en lugar de dos (como en las texturas 2D). Estas son más utilizadas para el mapeado de tonos, pero también pueden ser útiles para el renderizado de efectos volumétricos, como el humo, la niebla y los rayos.

Las matrices de texturas 2D contienen una serie de capas 2D separadas, las cuales un sombreador puede indexar para seleccionar sólo una de las texturas 2D contenidas.

Los objetos sampler son nuevos en WebGL 2. Estos desacoplan la forma en que se la textura se muestra de la textura seleccionada para el muestreo, por lo que se puede realizar el muestreo de una única textura de varias formas, y múltiples texturas pueden apuntar al mismo objeto sampler.

WebGL 2 también elimina las restricciones de las texturas non-power-of- two (NPOT).

Retroalimentación de transformación

La retroalimentación de transformación captura la salida del sombreador de vertex en un objeto de buffer, utilizando a menudo esta salida como entrada para el siguiente cuadro. Esto crea un bucle que no deja la GPU, liberando a la CPU de estos cálculos. Los sistemas de partículas suelen aprovechar ésto para iterar la posición de cada partícula y moverla en cada cuadro sin interacción de la CPU.

La retroalimentación de transformación también puede ser combinada con “rasterizer discard”, el cual permite correr el sombreador de vertex sin el sombreador de fragmentos. Esto permite flujos de procesamiento de datos naturales tipo “mapa” GPGPU (computación de uso general en GPU).

¡Y más!

Hay muchas más características que han llegado en WebGL 2, incluyendo Vertex Array Objects, MSAA renderbuffers y Uniform Buffer Blocks por nombrar algunas. Para una lista completa de todo lo nuevo en WebGL 2, puedes echar un vistazo a la especificación oficial, ya que sólo contiene las diferencias entre WebGL 1 y 2.

Algunas de estas características pueden ser vistas con relativo aislamiento en la página de ejemplos de WebGL 2. Estas demostraciones específicas de cada función sirven para ilustrar los nuevos efectos posibles con las nuevas características, así como para proporcionar código de ejemplo sobre cómo usarlas.

Lo que sigue

Estamos publicando la API para su uso generalizado, pero todavía hay más trabajo por hacer. Estamos deseando trabajar en mejorar el rendimiento, relajar algunas restricciones y mejorar el pulido general. Sabemos que todos tienen el rendimiento muy presente, por lo que tenemos un trabajo muy interesante en la trastienda para ofrecer aplicaciones con el rendimiento necesario para ofrecer experiencias aún más sofisticadas e impactantes.

Además de ver a las aplicaciones añadir soporte de WebGL 2, esperamos ver la integración de WebGL 2 en los frameworks y motores WebGL existentes. PlayCanvas soporta WebGL 2, como se muestra en nuestra destacada demostración After the Flood. Three.js también tiene soporte para utilizar WebGL 2. ¡Estate al tanto de otros motores que reciban soporte de WebGL 2 durante el año!

¿Algún problema? Por favor, registra un error en nuestro Bugzilla. (Recuerda: ¡también puedes usar GitHub para ingresar!)

Artículos relacionados:

Categorías: Mozilla Hispano

Mecanismos de control en juegos JavaScript

Noticias de Mozilla Hispano - Sáb, 07/10/2017 - 04:06

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

Las laptops, computadoras, smartphones, tablets, televisores, e incluso refrigeradores tienen una cosa en común — probablemente corren un navegador, así que probablemente puedas jugar un juego HTML5 en ellos. Renderizar el juego en pantalla es una cosa, pero también tienes que controlarlo de algun modo, y hay un montón de opciones diferentes adecuadas para varias plataformas. Desde táctiles, pasando por el ratón y el teclado, al gamepad, incluso un control remote de televisor o … plátanos — estas interfaces están cubiertas en una serie de nuevos artículos sobre mecanismos de control, ahora disponibles en la MDN.

Para mostrar su uso en la vida real en un proyecto, estos mecanismos de control están implementados en el juego de demostración de Captain Rogers: Battle at Andromeda desarrollado con Phaser, para que puedas ver cómo el juego se ve afectado por la plataforma. También puedes ver que no necesitas desarrollos separados para diferentes plataformas — la naturaleza multiplataforma de la Web puede ayudarte a ajustar los controles al dispositivo en el que se juega sin mucho esfuerzo de codificación.

Hay una pequeña demostración de controles en JavaScript puro de código abierto en GitHub, así que puedes ver exactamente cómo están implementados estos mecanismos, y pruébalos por ti mismo en tus propio entorno de desarrollo. Sumérgete en el código, o revisa lo más destacado de las partes clave a continuación.

Tacto en móviles

Vamos a empezar con el soporte de tacto en móviles debido al enfoque de móvil primero en los juegos HTML5:

document.addEventListener("touchstart", touchHandler); document.addEventListener("touchmove", touchHandler); function touchHandler(e) { if(e.touches) { playerX = e.touches[0].pageX - canvas.offsetLeft - playerWidth / 2; playerY = e.touches[0].pageY - canvas.offsetTop - playerHeight / 2; } }

Estas pocas líneas de código JavaScript son todo lo que necesitas para unos controles muy básicos en tu juego, para que puedas jugarlo en dispositivos móviles. Las primeras dos líneas inicializan los monitores de evento para los eventos táctiles en los que estamos interesados — cuando tocas la pantalla, y cuando deslizas tus dedos a través de ella. La función verifica si algunos toques son realizados, y luego establece las coordenadas del jugador para que la nave se pueda renderizar en el lugar correcto del lienzo del juego.

Esto sólo es lo básico, y tú puedes (y deberías) expandir las posibilidades, por ejemplo implementar multitoques o gestos. Todo depende de qué tipo de juego tienes, y qué debe ser controlado (y cómo). También puedes ofrecer botones en pantalla para realizar acciones, por ejemplo flechas de movimiento y un botón de disparo. Mira el artículo de controles táctiles para móvil para más detalles.

Mouse y teclado de escritorio

Ya que estamos hablando de “flechas de movimiento”, puedes imprimirlas en pantalla para dispositivos móviles, pero puedes implementarlas en escritorio también. Las teclas de cursor o teclas WASD son formas populares de mover un personaje en el juego. Por ejemplo, el siguiente caso maneja las techas de cursor:

document.addEventListener("keydown", keyDownHandler); function keyDownHandler(e) { if(e.keyCode == 39) { rightPressed = true; } else if(e.keyCode == 37) { leftPressed = true; } if(e.keyCode == 40) { downPressed = true; } else if(e.keyCode == 38) { upPressed = true; } }

Todo se trata de detectar constántemente y luego guardar la información sobre qué tecla fue presionada, para que pueda ser procesada en el bucle de dibujo:

function draw() { ctx.clearRect(0, 0, canvas.width, canvas.height); if(rightPressed) { playerX += 5; } else if(leftPressed) { playerX -= 5; } if(downPressed) { playerY += 5; } else if(upPressed) { playerY -= 5; } ctx.drawImage(img, playerX, playerY); requestAnimationFrame(draw); }

Las variables de las posiciones x y y del jugador son ajustadas y luego la imagen de una nave es movida al nuevo punto.

El mouse de escritorio y los toques móviles son muy similares desde el punto de vista de codificación: todo lo que necesitas haces es darle la información de en donde ocurre el click o el toque y actualizar la posición del juegador:

document.addEventListener("mousemove", mouseMoveHandler); function mouseMoveHandler(e) { playerX = e.pageX - canvas.offsetLeft - playerWidth / 2; playerY = e.pageY - canvas.offsetTop - playerHeight / 2; }

El evento mousemove es detectado, y la posición del jugador es ajustada para colocar la nave en el centro del puntero del mouse siempre que cambie. Eso es todo lo que necesitas para hacer tu juego jugable en escritorio usando tanto teclado y mouse — para más detalle, revisa el artículo controles de teclado y mouse en el escritorio.

Gamepad

Mi control favorito — uso la API Gamepad para controlar todas mis diapositivas basadas en HTML durante mis presentaciones. He hablado sobre esta API algunas veces, escrito un par de artículos, implementado algunos juegos, e incluido toda la información relevante en el Kit de Contenido del API Gamepad. Es realmente asombroso de seamos capaces de sentir la experiencia de una consola en una computadora. ¡Y funciona gracias a las tecnologías Web! Jugar Captain Rogers con un gamepad enriquese la experiencia y se siente mucho mejor.

Cubrir el soporte del API Gamepad es un poco más complejo que eventos de tacto y telcado, pero sigue siendo bastante sencillo:

window.addEventListener("gamepadconnected", gamepadHandler); function gamepadHandler(e) { controller = e.gamepad; } function gamepadUpdateHandler() { buttonsPressed = []; if(controller.buttons) { for(var b=0; b

Cuando el gamepad se conecta, se lanza un evento así que podemos obtener la referencia a sus datos en una variable que podemos usar después. En cada actualización, un nuevo arreglo de botones presionados es creado, así que el estado actual siempre será el útlimo. También hay una función que recorrerá el arreglo para ver si un botón específico que nos interesa se presiona. Esta información puede, entonces, ser usada en el bucle de dibujo, en una manera similar a la comprobación del teclado:

function draw() { // ... gamepadUpdateHandler(); if(gamepadButtonPressedHandler(0)) { playerY -= 5; } else if(gamepadButtonPressedHandler(1)) { playerY += 5; } if(gamepadButtonPressedHandler(2)) { playerX -= 5; } else if(gamepadButtonPressedHandler(3)) { playerX += 5; } if(gamepadButtonPressedHandler(11)) { alert('BOOM!'); } // ... }

Esa es la manera en que controlamos la nave del jugador presionando los botones DPad correspondientes, e incluso lanzar una explosión de bomba con el botón A. También puedes detectar los ejes, o incluso construir tu propia pequeña librería para manejar la entrada desde gamepad — revisa el artículo sobre controles de gamepad en el escritorio para más detalles sobre esto.

Controles no convencionales

Si gustas, puedes ir incluso más lejos y jugar con un control remoto en una gran pantalla de televisor en tu sala, agitando tu mano en frente de una laptop, o presionar alimentos cotidianos conectados con cables a tu PC.

Por ejemplo, el cotrol remoto de los televisores Panasonic es sorprendentemente fácil de implementar, ya que reusa los eventos de teclado, y las fechas direccionales tiene los mismos códigos que las teclas de cursor de teclado — 37, 38, 39 y 40, así que está listo para usar. Si necesitas más botones específicos, aquí tienes una lista completa, junto con información más detallada.

En lugar de presionar los botones en un control remoto, puedes usar la capacidad de dispositivos Leap Motion para detectar la posición de las manos y otros parámetros para tomar control de la nave del navegador sin tocar algún control. En un bule predefinido podemos obtener los detalles de las manos...

Leap.loop({ hand: function(hand) { horizontalDegree = Math.round(hand.roll() * toDegrees); verticalDegree = Math.round(hand.pitch() * toDegrees); grabStrength = hand.grabStrength; } });

y usarlos para actualizar la posición del jugador:

function draw() { // ... if(horizontalDegree > degreeThreshold) { playerX -= 5; } else if(horizontalDegree < -degreeThreshold) { playerX += 5; } if(verticalDegree > degreeThreshold) { playerY += 5; } else if(verticalDegree < -degreeThreshold) { playerY -= 5; } if(grabStrength == 1) { alert('BOOM!'); } // ... }

Podrás encontrar la implementación de otros mecanismos de control como el efecto Doppler, la API de Proximidad, o incluso Makey Makey en el artículo de controles no convencionales.

Resumen

Estos días, hay una gran cantidad de dispositivos, grandes y pequeños, en los cuales puedes jugar juegos HTML5. ¿Tu reloj? ¿Un juego web activado por voz? Las posibilidades son infinitas. Y recuerda: cuantos más mecanismos de control pueda soportar tu juego, mejor, ya que podrá ser jugado en un amplio rango de dispositivos, en todas las plataformas posibles. Toma ventaja de las oportunidades habilitadas por el navegador.

Artículos relacionados:

Categorías: Mozilla Hispano

SLUD 2017: Software libre, tecnología, desarrollo e Internet de las Cosas

Noticias de Mozilla Hispano - Lun, 02/10/2017 - 18:34

Mozilla Colombia participó de la Semana Linux en la Universidad Distrital -SLUD 2017- que se llevó a cabo del 28 de agosto al 2 de septiembre, organizada por el Grupo GNU/Linux de la Univerisdad Distrital (GLUD). El evento contó con la participación de más de 400 personas entre estudiantes, profesores, empresarios, representantes gubernamentales y más interesados en el software libre.

Durante el evento se reflexionó sobre el desarrollo, filosofía, uso y difusión del Software libre. Además, de las ventajas, alcances, progresos y también en la implementación del mismo para el progreso tecnológico de las sociedades. El objetivo fue el de promover el uso de software libre, la participación y reflexiones sobre el papel que cumple la tecnología en nuestras vidas, y como desde nuestro trabajo debemos priorizar pensar en el beneficio y desarrollo de las personas y sociedad en general.

A lo largo de esta semana, hubo conferencias, talleres, discusiones y también un hackathon de tecnología libre que se enfocó a Internet de las cosas (IoT). Por su parte Mozilla Colombia presentó la charla ‘Mozilla’s Open IoT Studio y Common Voice por Mozilla‘ en donde presentamos el estudio realizado por Mozilla sobre IoT, y cómo desde la comunidad venimos trabajando por prácticas y desarrollos responsables.

Nuestro interés se centra en que en los desarrollos se prioricen a las personas y también se conforme una red de profesionales de IoT que realizan investigaciones, hacen prototipos y construyen colaboraciones significativas. De igual forma, hablamos del proyecto Common Voice, cuyo objetivo es el de ayudar a que el reconocimiento de voz sea abierto para todos. Tanto Common Voices como Open IoT Studio son dos iniciativas de Mozilla, una comunidad de voluntarios que trabajamos por la Web abierta e inclusiva. A través de la innovación los Mozillians buscamos conseguir una meta común: Internet para las personas.

De igual forma este evento contó con la participación y el apoyo de grandes empresas y organizaciones que tienen y promueven culturas abiertas y libres lo que permitió mostrar los alcances del software libre e incrementar la confianza en su uso y desarrollo. Entre los participes estuvo también RedHat y Skinatech quienes compartieron y presentaron conferencias sobre algunos modelos de negocio del software libre. A su vez, Koghi dió su apoyo en la hackathón de IoT y por si fuera poco, durante la SLUD 2017 se llevó a cabo el lanzamiento del Portal de Software Público por parte del Ministerio de Tecnologías de la Información y Comunicaciones de Colombia.

El grupo GNU/Linux Universidad Distrital fue fundado en el 2002 como el primer grupo académico dedicado a software libre en el país. Su misión es fomentar el uso, apropiación y desarrollo de tecnología libre buscando su integración al desarrollo económico y social de la ciudad – región, con proyección en el ámbito nacional e internacional. Estos jóvenes trabajan de cerca con la administración distrital y el Ministerio de TIC y contribuyen con las decisiones en materia tecnológica de la ciudad de Bogotá. En el presente aparte de la Semana Linux, el colectivo trabaja en diferentes líneas de desarrollo como con Videojuegos, Realidad Aumentada, Seguridad informática y Hacking, Hardware abierto y libre, desarrollo en general y por supuesto GNU/linux.

El evento culminó con el hackathon enfocado a Internet de las Cosas (IoT). El hackathon consistió en realizar un proyecto de software libre implementando tecnologías de IoT, en el los participantes definían la idea de proyecto que querían trabajar durante la hackathon.

El proyecto ganador fue GeoSmart, desarrollado por un grupo de cuatro personas que ya venían trabajando desde antes en su idea de desarrollo. Este desarrollo consistió en un sistema de geolocalización de ambulancia, que en caso de un accidente de tránsito notificá a la ambulancia que se encuentra más cerca para que esta llegue lo más pronto posible al lugar de los hechos, de esta forma los pacientes o personas que soliciten el servicio serán atendidos de manera rápida y oportuna. Después de esto, se procederá a clasificar al paciente mediante una paleta de colores para remitirlo al hospital que cumpla con los requisitos, y se trazará la ruta mejor desde el lugar del accidente hasta el hospital seleccionado.

Fue una semana estupenda en donde se habló, promovió y vivió el software libre. La próxima versión de la Semana Linux tiene miras e interés en que sea más grande además de contar con la participación de más organizaciones, empresas, desarrolladores y comunidad en general. Así que desde ahora, todas las personas interesadas están invitadas a visitar los sitios Web, conocer los proyectos y participantes, seguirnos en nuestras redes sociales y estar pendientes de la próxima Semana Linux Universidad Distrital.

Escrito por Juan Velandia y Mónica Bonilla.

Artículos relacionados:

Categorías: Mozilla Hispano

¿Por qué WebAssembly es mas rápido que asm.js?

Noticias de Mozilla Hispano - Sáb, 30/09/2017 - 22:10

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

WebAssembly, es nuevo formato de ejecución para la Web, disponible en la versión estable de la mayoría de navegadores. Uno de los principales objetivos de WebAssembly es ser rápido. Esta entrada explicará detalles técnicos de cómo lo hace.

Por supuesto, “rápido” es relativo. Comparado con JavaScript y otros lenguajes dinámicos, WebAssembly es rápido porque es estáticamente tipado y simple para optimizar. Pero WebAssembly pretende ser tan rápido como el código nativo. asm.js ha estado muy cerca de ello, y WebAssembly cierra la brecha aún más. Esta entrada se enfoca en como WebAssembly es más rápido que asm.js.

Antes de empezar, hay algunas advertencias: el rendimiento es difícil de medir y tiene muchos aspectos. También, en la tecnología siempre van a existir casos donde aún no se han optimizado. Así que no todas las pruebas de rendimiento actuales serán rápidas para WebAssembly. Esta entrada describe cómo WebAssembly debería ser rápido; donde aún no es, es debido a bugs que se deben corregir.

Ahora veamos por qué WebAssembly es rápido:

1. Inicio

WebAssembly está diseñado para ser rápido de descargar y rápido de analizar gramaticalmente, así que incluso las aplicaciones de gran tamaño pueden iniciar rápidamente.

En realidad no es tan fácil mejorar el tamaño de descarga de un archivo de JavaScript minificado y comprimido con gzip, ya que es casi tan compacto como el código nativo. Aún así, el formato binario de WebAssembly puede seguir mejorando, siendo diseñado con cuidado para ser de poco tamaño (los índices son LEB128s, etc.). Suele ser aproximadamente 10–20% mas pequeño (comparado con archivos comprimidos con gzip).

WebAssembly mejora el análisis gramatical en una forma mas grande: puede ser interpretado en un orden de magnitud mas rápido que JavaScript. Esto se debe principalmente a que los formatos binarios son mas rápidos de interpretar, especialmente aquellos diseñados para ello. WebAssembly también facilita analizar (y optimizar) funciones en paralelo, lo cual ayuda mucho en máquinas con múltiples núcleos.

El tiempo total de arranque puede incluir factores mas allá de la descarga y análisis gramatical, tales como la optimización del código de la VM, o descarga de dependencias adicionales antes de la ejecución inicial, entre otros. Pero la descarga y análisis son inevitables y por ello es importante mejorar tanto como se pueda. El resto puede ser optimizado y mitigado, bien sea en el navegador o en la aplicación (por ejemplo, la optimización total del código puede ser evitada usando un compilador base o intérprete para WebAssembly, al inicio).

2. Características de CPU

Un truco que hizo asm.js tan rápido es que, a pesar de que todos los números en JavaScript son doubles, en asm.js tienen una operación and de bits al final, lo que hace que sea lógicamente igual a un CPU haciendo una suma de enteros, algo en lo que los CPU son muy buenos. Así que asm.js facilitó a las VM usar el poder de los CPUs al máximo.

Pero asm.js estaba limitado a cosas que son expresadas en JavaScript. WebAssembly no está limitado a ello y nos deja usar características adicionales de la CPU tales como:

  • Enteros de 64 bits. Las operaciones en ellos pueden ser hasta 4 veces mas rápidas. Esto permite acelerar algoritmos de cifrado, por ejemplo.
  • Traslado de carga y almacenamiento. Es una gran ayuda, básicamente en todo lo que use memoria de objetos con campos fijos (structs de C, entre otros).
  • Cargas y almacenamiento no alineado, evita la necesidad de asm.js de enmascarar (que asm.js lo hace para compatibilidad con los vectores tipados). Esto ayuda prácticamente con cualquier carga y almacenamiento.
  • Varias instrucciones de CPU como popcount, copysign, etc. Cada uno de éstos ayudan en circunstancias específicas (ejem. popcount puede ayudar en el cryptonalisis).

Qué tanto beneficiará una prueba de rendimiento específica dependerá del uso de las características mencionadas anteriormente. Generalmente vemos una mejora de velocidad del 5% en promedio respecto a asm.js. Las futuras mejoras mejoras esperadas son el soporte de instrucciones SIMD.

3. Mejoras en el ecosistema de herramientas

WebAssembly principalmente es un objetivo de compilación, y por lo tanto tiene 2 partes: compiladores que lo generan (el lado del conjunto de las herramientas), y las máquinas virtuales (VM) que lo ejecutan (el lado del navegador). Un buen rendimiento depende de ambos.

Este ya era el caso con asm.js, y Emscripten hizo muchas optimizaciones en el lado de las herramientas, corriendo optimizadores de LLVM y también el optimizador de asm.js de Emscripten. Para WebAssembly, se ha construido encima de ello, pero hemos añadido mejoras significantes mientras se hacía. Tanto asm.js como WebAssembly no son objetivos de compilación comunes, y en maneras similares, se aprendieron lecciones durante los días asm.js que ayudaron a hacer mejor las cosas para WebAssembly. Particularmente:

En general, estas mejoras ayudan tanto que migrar de asm.js a WebAssembly ayudo a mejorar un (7% y 5% en Box2D, respectivamente).

4. Buen rendimiento

asm.js podía correr básicamente a velocidad nativa, pero nunca pudo hacer de forma consistente en todos los navegadores. La razón es que unos los optimizaron para una manera y otros de otra forma, produciendo diferentes resultados. Con el tiempo las cosas empezaron a converger, pero el problema era que asm.js no era un estándar: era una especificación formal de un subconjunto de JavaScript, escrito por un solo proveedor, que vio gradualmente interés por otros creadores de navegadores.

WebAssembly, por otra parte, ha sido diseñado en conjunto por todos los principales navegadores. A diferencia de JavaScript, que se puede hacer rápido usando muchos métodos creativos, o asm.js, que podía hacerse rápido usando métodos sencillos pero no todos los navegadores lo hicieron. WebAssembly tiene más acuerdos de como se debe optimizar. Aún existe mucho campo para para la diferenciación de VMs (diferentes formas de realizar la compilación, AOT vs. JIT, entre otros.), pero una buena base de rendimiento predecible se puede esperar para toda la Web.

Artículos relacionados:

Categorías: Mozilla Hispano

WebVR para todos los usuarios de Windows

Noticias de Mozilla Hispano - Mar, 26/09/2017 - 03:02

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Sergio Carlavilla.

Con el lanzamiento de Firefox 55 el 8 de agosto, Mozilla se complace en anunciar la disponibilidad de WebVR 1.1 para todos los usuarios de 64-bit de Windows con un casco de realidad virtual de Oculus Rift o HTC VIVE. Desde que anunciamos esta característica hace dos meses, hemos visto un enorme crecimiento en las herramientas, contenido artístico y aplicaciones que se están produciendo para WebVR – echa un vistazo a algunos de los aspectos destacados en el siguiente vídeo:

Sketchfab también acaba de anunciar el soporte para exportar sus modelos 3D en el formato glTF y dispone de más de 100.000 modelos para su descarga bajo la licencia Creative Commons, por lo que es más fácil disponer de recursos de arte de alta calidad en tus escenas WebVR con librerías tales como three.js y Babylon.js y saber que funcionarán.

También es uno de los primeros sitios en sacar provecho de WebVR para crear un corto animado y resaltar la apertura de las URLs en el soporte de recorrido por medio de enlaces para crear experiencias impresionantes en VR dentro del contenido web.

El crecimiento en el número de nuevos usuarios que tienen sus primeras experiencias con el contenido WebVR también ha sido fenomenal. En el último mes, hemos visto más de 13 millones de usos de la librería A-Frame, iniciada aquí en Mozilla para hacer más fácil a desarrolladores web, diseñadores y personas de todas las disciplinas la creación de contenido WebVR.

No podemos esperar ver qué vas a construir con WebVR. Por favor, enséñanos lo que estás haciendo enviando un tweet a @MozillaVR o diciendo hola en el canal WebVR de Slack.

¡Mantente al tanto del anuncio del próximo concurso de A-Frame con aún más oportunidades para aprender, experimentar y obtener retroalimentación!

Artículos relacionados:

Categorías: Mozilla Hispano

Potentes adiciones al CSS Grid Inspector en Firefox Nightly

Noticias de Mozilla Hispano - Jue, 21/09/2017 - 21:37

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

CSS Grid está revolucionando el diseño web. Es un estándar de diseño flexible y simple que puede ser utilizado en todos los navegadores y dispositivos. Al igual que nosotros, los diseñadores y desarrolladores se están enamorando rápidamente. Es por eso que hemos estado trabajando duro en el panel de Layout en las herramientas de desarrollador de Firefox, añadiendo potentes actualizaciones al CSS Grid Inspector y al Box Model. Las últimas mejoras ya están disponibles en Firefox Nightly.

Mejoras del Layout Panel

El nuevo Layout Panel enumera todos los contenedores de CSS Grid disponibles en la página e incluye una superposición para ayudarte a visualizar el grid (cuadrícula) en sí. Ahora puedes personalizar la información mostrada en la superposición, incluyendo el número de líneas y dimensiones del grid.

Esto es especialmente útil si todavía te estás familiarizando con CSS Grid y su funcionamiento.

También hay un nuevo esquema interactivo del grid en la barra lateral. Pasa el puntero sobre el esquema para resaltar partes del grid en las páginas y mostrar información sobre el tamaño, el área y la posición.

La nueva configuración “Mostrar áreas del grid” muestra las áreas delimitadoras y el nombre de área asociado en cada celda. Esta funcionalidad fue inspirada por el CSS Grid Template Builder creado por Anthony Dugois.

Finalmente, el Grid Inspector es capaz de visualizar las transformaciones aplicadas al contenedor del grid. Esto permite a los desarrolladores ver con precisión dónde están en la página las líneas de su grid de entre los grids trasladados, sesgados, girados o escalados.

Box Model Panel mejorado

También hemos añadido un componente llamado Box Model Properties que muestra las propiedades que afectan a la posición, el tamaño y la geometría del elemento seleccionado. Además, podrás ver y editar las propiedades de la posición superior / izquierda / inferior / derecha y de altura / anchura, haciendo ajustes en vivo de forma rápida y fácil.

Por último, también podrás ver el desplazamiento del elemento superior para cualquier elemento posicionado, lo cual resulta útil para encontrar rápidamente elementos anidados.

Como siempre, queremos escuchar lo que te gusta o no te gusta y cómo podemos mejorar Firefox Dev Tools. Encuéntranos en Discourse o @firefoxdevtools en Twitter.

Agradecimientos a la comunidad

Han sido muchas las personas que han influenciado en la entrega del panel CSS Layout en Nightly, especialmente los equipos de Firefox Developer Tools y Developer Relations. Les damos las gracias por todas las contribuciones que han hecho para hacer que Firefox sea impresionante.

También recibimos un montón de ayuda de gente increíble de la comunidad, y los participantes en programas como Undergraduate Capstone Open Source Projects (UCOSP) y Google Summer of Code (GSoC). Muchas gracias a todos los colaboradores que ayudaron a traer funcionalidades a esta versión, incluyendo:

Micah Tigley – Estudiante de informática en la Universidad de Lethbridge, estudiante de Invierno 2017 de UCOSP, estudiante de Verano 2017 en GSoC. Micah implementó el contorno del grid interactivo y la visualización del área del grid.

Alex Lockhart – estudiante de la Universidad de Dalhousie, estudiante de Invierno 2017 UCOSP. Alex contribuyó al panel Box Model con información de las propiedades y posición del Box Model .

Sheldon Roddick – Estudiante en la Universidad de Rivers Thompson, estudiante de Invierno 2017 de UCOSP. Sheldon hizo una rápida contribución para añadir la capacidad de editar el ancho y la altura en el Box Model.

Si quieres convertirte en colaborador de Firefox Dev Tools, únete a GitHub o Slack o #devtools en irc.mozilla.com. Aquí encontrarás todos los recursos que necesitas para empezar.

Artículos relacionados:

Categorías: Mozilla Hispano

Mostrando tus experiencias con WebVR

Noticias de Mozilla Hispano - Mié, 20/09/2017 - 21:32

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

WebVR combina el poderoso alcance de la Internet con la atractiva inmersión del contenido de la realidad virtual. Con WebVR, una experiencia de realidad virtual está una URL de distancia. Sin embargo, el equipamiento VR todavía es muy costoso y no está completamente adoptado para el uso del consumidor. Por esta razón, es útil poder grabar tus proyectos VR para que otros puedan experimentar y disfrutar, al menos desde una perspectiva de espectador.

Grabando contenido VR

Este vídeo tutorial enseña cómo grabar una experiencia virtual que has creado usando el modo espejo en SteamVR. Capturar un ojo le permite a tu audiencia disfrutar el video en un modo 2D regular, pero capturar ambos ojos permitirá una experiencia más inmersiva gracias al vídeo estereoscópico.

Este tutorial asume que tienes una configuración compatible con SteamVR y Open Broadcast Software instalado.

Hay otras opciones para capturar tus experiencias VR. Si eres un usuario de Windows 10, quizás prefieras usar Game DVR, que funciona fuera de la caja.

Extraer un GIF de tu parte favorita

Ahora que tienes un video con tu contenido VR, puedes hacer un GIF de éste con Instagiffer para Windows. Instagiffer no es el software más rápido que existe, pero la calidad del resultado de los GIF es espléndido.

Inicia instalando e iniciando Instagiffer. La interfaz gráfica está dividida en tres secciones o pasos.

Haz click en Load Video en la sección Step 1, y selecciona el video del cual quieres extraer el GIF.

Localiza la secuencia que quieres convertir en GIF y llena las opciones en la sección Step 2. En este caso, queremos extraer 5.5 segundos de vídeo empezando desde el segundo 18; una secuencia en que le disparo a un enemigo.

Length, Smoothness y Frame Size afectarán al tamaño de tu GIF: valores más altos incrementarán el tamaño del archivo resultante.

En la sección Step 3, puedes recortar la imagen arrastrando los recuadros rojos. En este caso, estoy removiendo el marco negro alrededor del video. También puedes usarlo para aislar cada ojo por separado.

Ten en cuenta que el tamaño del GIF es mostrado en la esquina inferior derecha de la vista previa. Puedes ajustar el tamaño moviendo el deslizador de Frame Size en la sección Step 2.

Finalmente, haz click en el botón Create GIF! en la parte inferior de la ventana para empezar la conversión.

Una de las cosas que me gustan de Instagiffer es que, al terminar, mostrará mensajes de compatibilidad sobre el GIF, probándolo en algunos de los más populares servicios de Internet.

Haz click en el resultado final para ver la animación ¡Es realmente buena!

Si eres más de herramientas de la vieja escuela, puedes revisar la utilidad en línea de comandos de Kevin, Gifpardy y ver cómo funciona.

Haz un video 3D para YouTube

Una de las ventajas de grabar ambos ojos es que puedes ensamblar videos 3D lado a lado estereoscópicos. Puedes usar YouTube, por ejemplo.

Sólo sube tu video y edítalo. Ve a la pestaña Configuración avanzada dentro de la vista Información y configuración.

Haz clic en la casilla que dice Este es un video 3D y selecciona Lado a lado: Vídeo de la izquierda en el lado izquierdo de la lista desplegable.

Los mensajes de advertencia sobre depreciación alientan a que hagas eso fuera de línea, con tu editor de vídeo favorito.

Una vez que lo has hecho, YouTube seleccionará la mejor opción para mostrar el contenido en 3D, aplicando los filtros apropiados o las correcciones necesarias.

Por ejemplo, verás una representación de un anaglifo cuando revises tu vídeo con Firefox en el escritorio.

Puedes cambiar a una representación 2D también.

Cuando ves tu video con Firefox para Android verás ambos ojos lado a lado.

Y si pruebas con la aplicación nativa de YouTube, un ícono para Cardboard/Daydream VR aparecerá, transportándote a una sala de cine virtual en donde podrás disfrutar del video.

En conclusión

La realidad virtual no está completamente adoptada y tampoco es fácilmente accesible, pero las herramientas están disponibles para alcanzar más personas y distribuir tu trabajo creativo grabando tus demos de WebVR en vídeo. Descubre galerías VR en Twitter, GIPHY o Tumblr. ¡Escoge tus mejores videos y compártelos!

¿Prefieres vídeos en alta calidad? Revisa el contenido VR en YouTube o Vimeo.

En Mozilla, apoyamos el éxito de WebVR y apuntamos a demostrar que la gente puede compartir y disfrutar de experiencias de la realidad virtual en la Web. Por favor, comparte tus proyectos WebVR con el mundo. Amaremos lo que estás haciendo. Déjanos saber en Twitter etiquetando tus proyectos con #aframevr, ¡y te retuitearemos! Sigue a @AframeVR y @MozillaVR para conocer los últimos desarrollos y nuevos trabajos creativos.

Artículos relacionados:

Categorías: Mozilla Hispano

Fathom: un framework para entender las páginas web

Noticias de Mozilla Hispano - Sáb, 09/09/2017 - 20:12

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

Es hora de que vayamos más allá de un navegador que sólo muestre páginas web. En la web moderna, intentar completar una simple tarea puede hacer que seas golpeado por pop-overs, entrecerrar los ojos para ver el contenido empotrado en una columna diminuta, e intentar descubrir el comportamiento de otro widget personalizado de una página. Para restablecer el equilibrio de potencia y recuperar la eficiencia del usuario, necesitamos un navegador más inteligente.

Imagina que Firefox comprendiese las páginas como lo hace un humano:

  • Los inicios de sesión arduos podrían ser cosa del pasado. El navegador podría reconocer un enlace de inicio de sesión, seguirlo en segundo plano e iniciar sesión, todo ello sin perder su lugar. Los enlaces podrían desaparecer de la página y ser movidos a una interfaz de usuario de navegador estándar.
  • Los productos podrían ser reconocidos como tales y manipulados como trozos cohesivos. Podrías arrastrarlos a un carrito de compra, completo con imágenes y precios, para la comparación de compras en múltiples sitios. Podrías disfrutar de columnas fácilmente escaneables en lugar de un circo de pestañas.
  • Al fin podría eliminarse la interfaz ineficiente e incoherente. Podríamos tener teclas de acceso rápido proporcionadas por el navegador para descartar pop-overs, navegar a la siguiente página lógica, estandarizar el aspecto de los elementos de la interfaz o reconocer y allanar las presentaciones de diapositivas innecesariamente paginadas.
  • En pantallas pequeñas o ventanas, la navegación superflua o secciones de cabecera podrían ocultarse, incluso en las páginas que no utilizan un diseño web adaptable. Podríamos imaginar inteligentemente qué imprimir, incluso en ausencia de hojas de estilo de impresión.

Estos posibles futuros suponen que el navegador puede identificar partes significativas de la página. Durante décadas, han habido muchos intentos de hacer esto más fácil. Pero los microformatos, las etiquetas semánticas, el RDF y los elementos de encabezado link / rel no han podido hacerse cargo del mundo, debido tanto al incentivo de las páginas para permanecer sin posibilidad de ser raspadas como al trabajo extra que representan. Como resultado, los motores de búsqueda modernos y los modos de lectura de los navegadores han adoptado un tono alternativo: extraen el significado aceptando el desorden, yendo directamente a través de un marcado no semántico con un cinturón de herramientas lleno de heurísticas.

Pero un problema continúa: estos proyectos son de un solo propósito y costosos de producir. Readability, la base de los modos de lectura de Safari y Firefox, es de 1800 líneas de JavaScript y se cerró recientemente. El DOM Distiller de Chrome tiene 23000 líneas de Java. Estos enfoques imperativos se atascan en los mecanismos de recorrer el DOM y la acumulación del estado, oscureciendo las partes operativas de los “entendedores” y haciéndolos difíciles de escribir y difíciles de comprender. Están más enredados con los sistemas improvisados de puntuación difusos y la heurística específica de la página que necesitan incluir. La economía está en contra de ellos desde el principio, y consecuentemente pocos de ellos son creados, especialmente fuera de las grandes organizaciones.

¿Pero qué sería si los “entendedores” fuesen baratos escribir? ¿Qué pasa si Readability se pudiese implementar con tan solo 4 simples reglas?

const rules = ruleset( rule(dom('p,div,li,code,blockquote,pre,h1,h2,h3,h4,h5,h6'), props(scoreByLength).type('paragraphish')), rule(type('paragraphish'), score(fnode => (1 - linkDensity(fnode, fnode.noteFor('paragraphish') .inlineLength)) * 1.5)), rule(dom('p'), score(4.5).type('paragraphish')), rule(type('paragraphish') .bestCluster({splittingDistance: 3, differentDepthCost: 6.5, differentTagCost: 2, sameTagCost: 0.5, strideCost: 0}), out('content').allThrough(domSort)) );

Eso se sitúa dentro del 7% de la salida de Readability en una selección de sus propios casos de prueba, medida por la distancia de Levenshtein1. El marco de trabajo que permite esto es Fathom, y dirige el coste de escribir “entendedores” a través del piso.

Fathom es un mini-lenguaje para escribir extractores semánticos. Los conjuntos de reglas que componen sus programas están incrustados en JavaScript, por lo que puedes utilizarlos en el lado del cliente o servidor tal y como dicta la privacidad. Y Fathom maneja toda tu contabilidad para que puedas concentrarte en tus heurísticas:

  • El recorrer por árboles desaparece. Fathom es un lenguaje de flujo de datos como Prolog, por lo que los datos “aparecen” convenientemente cuando existen reglas aplicables que aún no se han visto.
  • El control de flujo desaparece. Fathom determina el orden de ejecución basado en dependencias, ejecutando sólo lo que necesita para responder a la consulta y almacenando en caché los resultados intermedios.
  • La tentación de escribir sistemas de plugins desaparece. Las reglas de Fathom están desordenadas, por lo que se pueden añadir otras tan fácilmente como añadir un nuevo elemento a una matriz de JavaScript. Esto hace que los programas Fathom (o conjuntos de reglas) se conecten de forma inherente. Se mezclan como corrientes de agua, sólo teniendo que ponerse de acuerdo sobre los nombres de los tipos, haciéndolos maduros para la experimentación colaborativa o la envoltura especial sin hacer un lío.
  • La necesidad de mantener estructuras de datos paralelas al DOM desaparece. Fathom proporciona nodos DOM de proxy en los que puede hacer garabatos, junto con un sistema en blanco y negro de tipos y un sistema de puntuación de grises para clasificar los nodos y guiar las decisiones.
  • La necesidad de encontrar el equilibrio óptimo de pesos para tu heurística desaparece, gracias a un arnés de optimización basado en recocido simulado. Todas esas constantes numéricas en el código anterior se descubrieron incitando a la máquina en una selección de entrada y salida correcta y alejándose.

La mejor parte es que los conjuntos de reglas de Fathom son datos. Se parecen a las llamadas de función JavaScript, pero las llamadas sólo hacen anotaciones en una especie de árbol de sintaxis, haciendo que todo sea fácilmente manipulable por una máquina. Hoy en día, eso nos lleva a la mejora automática de constantes de puntuación. ¡Mañana podría conseguirnos la generación automática de reglas por ellos mismos!

Fathom es joven pero febril. Ya está en producción, alimentando el Flujo de Actividad de Firefox (Activity Stream), donde selecciona descripciones de páginas, imágenes principales, etc. En 70 líneas, reemplazó un conocido servicio comercial de análisis de metadatos.

Lo que necesitamos ahora es imaginación. Recoger todas esas ideas que descartamos porque requerían demasiada comprensión por el navegador. Podemos hacer eso ahora. Es barato.

¿Tienes una idea? ¡Estupendo! Echa un vistazo a la documentación completa para empezar, toma el paquete npm, envía parches y únete a nosotros en el canal #fathom en irc.mozilla.org y en la lista de correo a medida que construyes. Vamos a hacer un navegador que sea, de forma audaz, ¡el agente del usuario!

1Las salvedades del ejemplo son bastante manejables. Es más lento que Readability, porque el agrupamiento es O (n2 log n). Pero también hay muchos pendientes sencillos que no se han tomado todavía: no hacemos nada en lo anterior para aprovechar las clases CSS o las etiquetas semánticas como <article>, ambas fuentes ricas de indicaciones, y no tratamos de reducir los candidatos a la agrupación con umbrales. Finalmente, parte de la diferencia del 7% representa en realidad mejoras sobre la salida de Readability.

Artículos relacionados:

Categorías: Mozilla Hispano

Firefox 55: el primer navegador con soporte para WebVR

Noticias de Mozilla Hispano - Mar, 05/09/2017 - 03:54

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

Soporte WebVR en el Firefox de escritorio

Firefox para Windows es el primer navegador de escritorio que soporta el nuevo estándar WebVR (¡y el soporte para Mac OS ya está en Nightly!). Como los creadores de WebVR, Mozilla quería que representara los mismos principios de estandarización, apertura e interoperabilidad que son las características de la Web, por lo que WebVR funciona en cualquier dispositivo: Vive, Rift y más.

Para obtener más información, echa un vistazo a vr.mozilla.org, o indaga sobre A-Frame, un framework de código abierto para construir experiencias de realidad virtual en la Web.

Nuevas funcionalidades para desarrolladores

Firefox 55 tiene soporte para nuevas funcionalidades de ES2017/2018, incluyendo los generadores asíncronos y los operadores rest y spread(“...“) para objetos:

let a = { foo: 1, bar: 2 }; let b = { bar: 'two' }; let c = { ...a, ...b }; // { foo: 1, bar: 'two' };

MDN tiene una gran documentación sobre el uso de ... con arrays literales o para la asignación por desestructuración, y la propuesta TC39 también proporciona una descripción concisa de esta funcionalidad.

En las herramientas de desarrollador, el panel de red ahora permite el filtrado de resultados mediante consultas como “status-code:200“.

También hay nuevas columnas opcionales para cookies, protocolo, esquema y más que se pueden ocultar o mostrar en el Panel de Red, tal y como se ve en la captura de pantalla anterior.

Haciendo Firefox más veloz

Hemos implementado varias nuevas funcionalidades para mantener la ejecución de Firefox rápida:

  • Las nuevas instalaciones de Firefox en Windows ahora tendrán por defecto una versión más estable y segura de 64 bits. Las instalaciones existentes se actualizarán a 64 bits con nuestra próxima versión, Firefox 56.
  • Restaurar una sesión o reiniciar Firefox con muchas pestañas abiertas ahora es un orden de magnitud más rápido. Por razones desconocidas, Dietrich Ayala tiene un perfil de Firefox con 1691 pestañas abiertas. Con Firefox 54, iniciar su instancia de Firefox llevaba 300 segundos y 2 GB de memoria. Hoy en día, con Firefox 55, tarda sólo 15 segundos y 0,5 GB de memoria. Esta mejora se debe principalmente al trabajo incansable de un colaborador externo, Kevin Jones, que prácticamente eliminó los costes fijos asociados a la restauración de pestañas.
  • Ahora los usuarios pueden ajustar el número de procesos de contenido de Firefox desde las Preferencias. Los procesos de contenido múltiples debutaron en Firefox 54, y permiten al navegador aprovechar mejor las CPUs multi-core modernas, sin dejar de respetar el uso de memoria RAM.
  • Firefox ahora utiliza sus listas de protección contra el rastreo integradas para identificar y retrasar los scripts de rastreo que se ejecutan en las páginas en segundo plano. Después de un corto período, Firefox aumentará el setInterval o setTimeout mínimo para las devoluciones de llamada programadas por scripts de rastreo a 10 segundos mientras la pestaña está en segundo plano. Esto se suma a nuestra habitual regulación de 1 segundo para las pestañas en segundo plano, y ayuda a garantizar que las pestañas no utilizadas no pueden estropear el rendimiento o la duración de la batería. Por supuesto, las pestañas que están reproduciendo audio o video no se regulan, por lo que la música de una pestaña de fondo no se entrecorta.
  • Con el anuncio del final de Flash, y en coordinación con Microsoft y Google, Firefox 55 requiere ahora que los usuarios hagan clic explícitamente para activar Flash en páginas web mientras trabajamos juntos para eliminar completamente Flash de la plataforma web en el 2020.
Haciendo más rápida la web

Firefox 55 introduce algunas nuevas características de bajo nivel que ayudan a mejorar el rendimiento de las aplicaciones web más exigentes:

  • La API IntersectionObserver permite al navegador responder a la visibilidad de los elementos de una página de manera mucho más eficiente y confiable que las soluciones existentes con polling o películas Flash invisibles. Puedes leer más en mi artículo sobre IntersectionObserver de la semana pasada.See the Pen Hello IntersectionObserver by Dan Callahan (@callahad) on CodePen.
  • Los objetos SharedArrayBuffer y Atomics son nuevos tipos primitivos de JavaScript que permiten a los workers compartir y acceder simultáneamente a la misma memoria. Esto finalmente hace que el multihilo (multi-threading) eficaz sea una realidad en la Web. ¿Cuál es el único inconveniente? Los desarrolladores tienen que preocuparse por la seguridad del hilo, de los mutex, etc. al compartir la memoria, al igual que en cualquier otro lenguaje multihilo. Puedes obtener más información sobre SharedArrayBuffer en esta introducción ilustrada y este artículo explicativo del año pasado.
  • La API requestIdleCallback () ofrece una nueva forma de programar devoluciones de llamada siempre que el explorador tenga unos milisegundos adicionales, milisegundos no utilizados entre cuadros (frames) o cada vez que haya transcurrido un tiempo máximo de espera. Esto hace posible comprimir el trabajo en los márgenes donde el navegador estaría inactivo y diferir el trabajo de menor prioridad mientras el navegador está ocupado. El uso de esta API requiere un poco de finura, pero MDN tiene una gran documentación sobre cómo usar requestIdleCallback() de manera efectiva.
Haciendo la Web más segura

La geolocalización y el almacenamiento se unen a las filas de las poderosas API que al igual que los Service Workers sólo se permiten en entornos seguros https://. Si tu sitio necesita un certificado TLS, considera Let’s Encrypt: una autoridad de certificado completamente gratuita, automatizada y sin ánimo de lucro.

Además, Firefox 55 no permitirá que los plug-ins se carguen desde o en esquemas que no sean HTTP/S, como file:.

Nuevas APIs WebExtensions

WebExtensions ahora puede:

Y más …

Hay muchos más cambios mientras nos preparamos para la próxima era de Firefox en noviembre. Algunos usuarios de Firefox 55 comenzarán a ver la nueva funcionalidad de capturas de pantalla de Firefox (Firefox Screenshots), la barra lateral de marcadores/historia ahora se puede acoplar a ambos lados del navegador y acabamos de anunciar tres nuevos experimentos en Test Pilot.

Para obtener una visión general y completa de las novedades, consulta las notas de versión oficiales, Firefox 55 para desarrolladores de MDN y el anuncio del blog de Mozilla.

Artículos relacionados:

Categorías: Mozilla Hispano

Presentación del Extension Compatibility Tester

Noticias de Mozilla Hispano - Jue, 31/08/2017 - 02:35

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

Con el paso de Firefox a una moderna API de extensiones de estilo web para el navegador, ahora es posible mantener un solo un código fuente y publicar una extensión en varios navegadores. Sin embargo, como los distintos navegadores pueden tener diferentes habilidades, algunas extensiones pueden requerir modificaciones para ser realmente portables. Con esto en mente hemos creado el Extension Compatibility Tester (verificador de compatibilidad de extensiones) para dar a los desarrolladores una mejor idea de si sus extensiones funcionarán en Firefox.

La herramienta actualmente admite archivos de extensiones de Chrome (.crx), pero estamos trabajando en ampliar los tipos de extensiones que puede comprobar. La herramienta genera un informe que muestra los posibles usos de las API o permisos incompatibles con Firefox, junto con los siguientes pasos a dar sobre cómo distribuir a los usuarios de Firefox una extensión compatible.

Seguiremos participando en el Grupo de Comunidades de Extensiones para el Navegador y apoyando su objetivo de encontrar un subconjunto común de puntos extensibles en navegadores y APIs que los desarrolladores puedan usar. ¡Esperamos que pruebes la herramienta y nos cuentes lo que piensas!

¡Pruébalo!

“La herramienta dice que mi extensión puede no ser compatible”

¡No es para preocuparse! Nuestro análisis solo muestra el uso de APIs y los permisos, y no dispone del contexto completo. Si la funcionalidad incompatible no es esencial para tu extensión, puedes utilizar las pruebas de prestaciones para utilizar sólo la API cuando esté disponible:

// provoca un error browser.unavailableAPI(...); // ¡prueba de soporte! if ('unavailableAPI' in browser) {     browser.unavailableAPI(...); }

Además, estamos ampliando constantemente las API de extensiones disponibles, por lo que puede que una funcionalidad que ahora no está disponible ¡esté a tan sólo unas pocas semanas de estarlo!

“¡La herramienta dice que mi extensión es compatible!”

¡Hurra! Dicho esto, sin duda prueba tu extensión en Firefox antes de enviarla para asegurarte de que las cosas funcionan como esperas. Las API más comunes pueden tener efectos distintos en navegadores diferentes.

“No quiero subir mi código a un sitio web de terceros”

¡No hay problema! Las pruebas de compatibilidad están disponibles como parte de nuestra herramienta de desarrollo de extensiones para línea de comandos o como un módulo independiente.

Si tienes algún problema al usar la herramienta, por favor reporta un problema o deja un comentario aquí. La esperanza es que esta herramienta sea un primer paso útil para ayudar a los desarrolladores a portar sus extensiones, y obtener un ecosistema de extensiones más saludable y más interoperable.

¡Esperamos que disfrutes portando!

Artículos relacionados:

Categorías: Mozilla Hispano

Simplificando los Canales de Distribución de Firefox

Noticias de Mozilla Hispano - Mar, 29/08/2017 - 04:31

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks. Traducción por Uriel Jurado.

Agilizar nuestro proceso de entrega y llevar rápidamente nuevas características a la versión estable para usuarios y desarrolladores es una prioridad para Firefox.  Mirando de cerca y de forma crítica nuestros canales de entrega, quedó en claro que Aurora no reunía nuestras expectativas como primer canal de estabilización.

El 18 de Abril (del 2017), el canal Aurora de Firefox dejó de actualizarse, y durante los siguientes meses, Aurora fue removido del ciclo de entrega. La edición para desarrolladores ahora está basada en la versión Beta. Los usuarios de la edición para desarrolladores mantienen sus temas, herramientas y preferencias. Siguen manejando su perfil actual y no tendrían que experimentar ningún inconveniente.

Este cambio beneficia a los desarrolladores de muchas formas:

  • Elecciones más simples sobre los canales de prelanzamiento: Nightly para características experimentales y la versión para desarrolladores/beta para estabilidad.
  • Mayor calidad y un entorno más estable para los usuarios de la versión para desarrolladores.
  • Un ciclo de entrega más rápido de nuevas características. (¡Beneficiándonos a todos!)

Aquí está la línea del tiempo: el 18 de abril, el código de Firefox 54 se cambió de Aurora a Beta como siempre, mientras Firefox 55 se mantuvo en Nightly para un segundo ciclo seguido (un total de 14 semanas). En el siguiente día de actualización, junio 12, Firefox 55 se movió directamente desde Nightly a Beta. Entre abril y junio, Firefox Aurora para escritorio (54) siguió recibiendo actualizaciones críticas de seguridad, y los usuarios de Aurora y de la versión para Desarrolladores fueron migrados al canal Beta. En Android, los usuarios de Aurora fueron migrados a Nightly.

Aurora fue originalmente creado en 2011 para brindar una mayor retroalimentación por parte de los usuarios después de que Firefox se actualizara de la versión 5 a un ciclo de entregas de alta velocidad. Hoy, en 2017, tenemos procesos más modernos sosteniendo nuestro modelo de trenes, y creemos que podemos entregar productos estables y ricos en características sin la fase adicional de 6-8 semanas de Aurora.

Un proceso de despliegue escalonado, similar a lo que hacemos actualmente con la versión estable, será utilizado para las primeras semanas de Beta. Nuestro flujo de trabajo de entrega e ingeniería continuará teniendo revisiones adicionales y ajustes para asegurarnos que entregamos una versión de alta calidad. Una nueva característica se añadirá de Nightly a Beta solo cuando sea considerada lista, basados en criterios preestablecidos determinados por nuestros equipo de ingeniería, producto y de integridad de producto. Si las nuevas características no están listas, no serán migradas de Nightly a Beta.

Las nuevas herramientas y procesos incluyen:

  • La integración de analizadores fijos como parte del flujo de trabajo, para detectar fallas durante la fase de revisión. Estos serán capaces de identificar defectos potenciales, minimizando la deuda técnica.
  • Los resultados de la cobertura de código serán usados para analizar la calidad de la plataforma de pruebas y el riesgo de realizar el cambio.
  • La habilidad de identificar riesgos potenciales producidos por cambios incluso antes de ser realizados, relacionando datos de varias fuentes (VCS, Bugzilla, etc.) Esto para identificar funciones en donde una modificación seguramente conllevaría a una regresión.
  • Monitoreando la cantidad de fallas, control de calidad, datos de telemetría y nuevas regresiones, para determinar la calidad en general de Nightly y la preparación de características para ser agregadas a Beta.

Para saber un poco más respecto a los detalles de esta transición, por favor visita el blog de Administración de Versiones de Mozilla, donde encontrarás respuestas más profundas respecto a las preguntas más frecuentes relacionadas a este cambio.

Artículos relacionados:

Categorías: Mozilla Hispano

Inspecciona, modifica, y depura React y Redux en Firefox

Noticias de Mozilla Hispano - Vie, 25/08/2017 - 01:15

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

React, en conjunto con Redux, son uno de los frameworks para interfaces de usuario más rápidos y flexibles que existen para la web. Es fácil de escribir, de usar y excelente para equipos. De hecho, la comunidad de Mozilla utiliza React para construir gran parte de la interfaz de las herramientas de desarrollo de Firefox, y la famosa interfaz de usuario de Facebook está escrita con React. A pesar de su popularidad, aún no es fácil de depurar React desde el navegador. Las herramientas de desarrollo de React de Facebook y las herramientas de desarrollo de Redux de Zalmoxisus te dejan inspeccionar, modificar y depurar tu código desde el navegador. Y ahora están disponibles para Firefox. Estos complementos y otros como el complemento de Vue para Firefox harán la depuración de frameworks de JavaScript mas fácil. Cuando se combinan con la herramienta Debugger.html de Mozilla, permiten que todas estas herramientas transformen tu navegador en un excelente depurador de código.

React

Obtén la última versión del complemento React DevTool desde aquí. Una vez instalado, podrás examinar código de React en cualquier sitio que lo utilice. Cuando visitas un sitio construido en React, el ícono del complemento aparecerá en la derecha de la barra de direcciones de Firefox:

Abre tus herramientas de desarrollo con la combinación de teclas Command-Option-i (Ctrl-Shift-i para Windows), haz click en el botón de la barra de las herramientas o haz clic derecho en la página y luego selecciona “Inspeccionar”. Verás el panel de React en conjunto con los otros paneles de las Herramientas de desarrollo. El panel principal ahora te mostrará el código de React:

La herramienta de React funciona muy parecido como cualquier otra herramienta de desarrollo. Utiliza las teclas direccionales o las teclas h,j,k,l para navegar en el código, haz click derecho en los componentes para examinarlos en el panel de elementos, mostrar la fuente y así. Puedes expandir los elementos al hacer click en las flechas.

El panel lateral es un gran lugar para almacenar variables y ver las actualizaciones del código.

También posee una barra genial para búsquedas.

Inspecciona un elemento de React en una página utilizando el inspector por defecto, entonces cambia a la pestaña de React. Entonces el elemento estará seleccionado automáticamente en el árbol de React.

También puedes hacer clic derecho en un elemento y seleccionar “Encontrar nodo DOM” para, bueno, encontrar el nodo DOM de cualquier elemento.

Redux

React y Redux van de la mano. Redux crea un contenedor de estado predictivo para que tu librería de React pueda ejecutarse virtualmente en cualquier sistema de forma confiable. También te permite viajar en el tiempo a una versión anterior de tus estados. Las herramientas de desarrollo de Redux para Firefox te permite inspeccionar acciones de  Redux y cargas, cancelar acciones, registrar errores de las acciones y automáticamente revaluar acciones a medida que cambias el código de reducer.

Las herramientas de desarrollo de Redux poseen gran documentación en inglés en su repositorio de GitHub, incluyendo argumentos, métodos, e inclusive un tutorial de como crear una tienda en Redux para depurar. ¡Chequéalos!

Con los complementos de Firefox, puedes tener un conjunto de herramientas para depurar React/Redux directamente desde el navegador. Descarga Firefox Edición para Desarrolladores y entonces puedes chequear todos los complementos disponibles en addons.mozilla.org.

Artículos relacionados:

Categorías: Mozilla Hispano

El navegador ligero: Firefox Focus hace menos, lo que es mucho más

Noticias de Mozilla Hispano - Mar, 22/08/2017 - 10:00

Esta es una traducción del artículo original publicado en el blog de Mozilla.

¡Firefox tuvo un bebé y lo llamó Focus! Firefox Focus es el nuevo navegador privado para iOS y Android, hecho para aquellas ocasiones en las que sólo precisas algo sencillo y ligero para hacer aquello que necesites y seguir con tu vida.

Focus es ideal para tareas que no necesitan un “uso excesivo del navegador”. El exceso ocurre cuando el software utiliza una cantidad máxima de la capacidad de procesamiento y recursos de tu dispositivo en ocasiones en las que un uso mínimo habría funcionado bien. El exceso puede hacer que el uso de Internet se perciba lento, sin respuesta y que no valga la pena el esfuerzo. El exceso envía tus datos a rastreadores de terceros.

Por ejemplo, si necesitas entrar en Internet para buscar el verdadero nombre de Muddy Waters, y en lugar de “McKinley Morganfield”, obtienes anuncios emergentes, pérdidas de control de pantalla, contenido “patrocinado” y otras actividades de distracción dirigidas por terceros, entonces sabes lo que se siente con el uso excesivo del navegador. Te cuesta demasiado tiempo perdido y privacidad como para justificar la simple pregunta que querías buscar.

Simplificar

En lugar de muchas funciones y complementos, Focus tiene tan sólo una pestaña; una cantidad mínima de botones; no hay contraseñas almacenadas o saturación del ancho de banda; y no recordará tu historial. Focus también bloquea los rastreadores de terceros de forma automática, ofreciendo una experiencia de búsqueda y navegación móvil más rápida y privada.

Así que cuando valores la velocidad y simplicidad en una sesión rápida, ¡usa Firefox Focus! Añade la aplicación de Android o iOS a tu rutina de navegación privada y observa lo que un navegador construido a propósito de forma ligera puede aportar a tu concentración y paz mental.

Puedes descargar Firefox Focus en Google Play o en la App Store.

Artículos relacionados:

Categorías: Mozilla Hispano

Haciendo un cambio con Pootle

Noticias de Mozilla Hispano - Lun, 21/08/2017 - 16:57

Esta es una traducción del artículo original publicado en el blog de Mozilla

A partir del 1 de septiembre de 2017, la instancia Pootle de Mozilla (mozilla.locamotion.org) se desactivará. Desde este momento hasta entonces, los responsables del equipo de localización ayudarán a las comunidades que estén utilizando Pootle a migrar todos los proyectos a Pontoon. El impacto positivo que ha tenido Pootle en la evolución continua de Mozilla es innegable y les damos las gracias por todas sus contribuciones a lo largo de los años.

La historia de la localización de Mozilla ha evolucionado con el tiempo. Si bien nuestra misión de mejorar la accesibilidad lingüística en la Web y en el navegador no ha cambiado, el proceso y las herramientas que nos ayudan a lograrlo han ido cambiado con los años. Algunos de nosotros podemos recordar cuando un localizador de Mozilla necesitaba ser experto en sistemas de control de versiones, comandos de Unix, editores de texto y Bugzilla con el fin de hacer una contribución l10n. Con el tiempo (y de muchas formas gracias a Pootle), quedó claro que la barrera técnica de entrada nos impedía realmente alcanzar nuestra misión. Empezando con Pootle (Verbatim) y Narro, nos propusimos reducir esa barrera a través de sistemas de gestión de traducción de código abierto basados ​​en la web. Estos eliminaron muchos de los requisitos técnicos de los localizadores, lo que a su vez nos llevó a ser capaz de ofrecer Firefox en idiomas que otros navegadores no podían o que simplemente ni lo harían; ¡Convirtiendo así a Firefox en el navegador más localizado del mercado!

Gracias a Pootle hemos aprendido que optimizar el impacto de l10n a través de estas herramientas es crítico para nuestra capacidad de cambiar y adaptarnos a nuevos y más rápidos procesos de desarrollo que están tomando las industrias de Internet y de software. Hemos creado Pontoon para llevar esto más allá y centrarnos en la localización con contexto. La demanda de esta herramienta se hizo tan grande que terminamos añadiendo más y más proyectos a la misma. Hoy anunciamos el siguiente paso en nuestra evolución: a partir del 1 de septiembre de 2017, todas las comunidades de Mozilla l10n que utilicen Pootle serán migradas a Pontoon y la instancia Mozilla Pootle (mozilla.locamotion.org) se desactivará.

¿Por qué?

Con el paso de los años hemos desarrollado una relación muy buena con Translate House (la organización detrás de Pootle), al igual que muchos miembros de la comunidad de localizadores de Mozilla. Hace casi cinco años, realizamos un contrato con el equipo de Translate House para mantener una instancia de Mozilla de Pootle en ejecución, para desarrollar funcionalidades personalizadas para esa instancia y para mentorizar comunidades l10n. Como l10n ha ido cambiando en Mozilla año tras año, el equipo de l10n se encontró recientemente como parte de otra reorganización interna, justo en el momento en que la renovación del contrato estaba en discusión. Con esa reorganización, surgieron nuevas prioridades para l10n y un cambio en el presupuesto para el próximo año. Frente a esos cambios, no pudimos renovar nuestro contrato con Translate House.

¿Qué ocurrirá ahora?

Antes del 1 de septiembre, los responsables de l10n se pondrán en contacto proactivamente con las comunidades l10n que usan Pootle para realizar las migraciones del proyecto a Pontoon. Migrando proyecto a proyecto, comenzaremos con los paquetes de idiomas que estamos entregando actualmente para un proyecto, luego nos moveremos a las que están en pre-lanzamiento, y finalmente a aquellas que han tenido actividad en los últimos tres meses. En el proceso buscaremos cualquier asunto técnico desconocido que los ingenieros de Pontoon puedan abordar para hacer la transición de forma positiva y sin problemas.

Hay algunas cosas que puedes hacer para que la transición se ejecute sin problemas:

  1. Inicia sesión en Pontoon con tu cuenta de Firefox. Si aún no tienes una cuenta de Firefox, crea una.
  2. Procesa todas las sugerencias pendientes en tus proyectos Pootle (es decir, lleva la cola de sugerencias de tu comunidad a 0).
  3. Asigna los problemas con Pontoon a los responsables de l10n de modo que podamos clasificarlos y abordarlos de manera oportuna. Para hacer esto, por favor, reporta un error aquí, o contacta con los responsables de l10n si no estás todavía cómodo con Bugzilla.

Entendemos que este es un cambio importante para aquellos que en este momento contribuyen con Mozilla a través de Pootle. Sabemos que el cambio de herramientas te hará menos productivo por un tiempo. Hemos creado este FAQ para ayudar a responder cualquier pregunta pendiente.

Por último, quisiera dar las gracias personalmente a Translate House. Su impacto en la localización de código abierto es incomparable y realmente he disfrutado de las relaciones que hemos construido con ese equipo. Les deseamos lo mejor en el futuro y esperamos tener oportunidades de colaborar y estar juntos para apoyar la localización abierta en el futuro.

Artículos relacionados:

Categorías: Mozilla Hispano

La Iniciativa de Información de Confianza de Mozilla: Construyendo un movimiento para combatir la desinformación en Internet

Noticias de Mozilla Hispano - Jue, 17/08/2017 - 17:27

Esta es una traducción del artículo original publicado en el blog de Mozilla.

Hoy anunciamos el proyecto Mozilla Information Trust Initiative (MITI), un esfuerzo integral para mantener Internet creíble y saludable. Mozilla está desarrollando productos, estudios y comunidades para luchar contra la contaminación de la información y las llamadas “falsas noticias” en línea. Y estamos buscando socios y aliados para ayudarnos a hacerlo.

Aquí está el por qué.

Imagínate esto: Dos artículos de noticias se comparten simultáneamente en línea.

La primera es una historia profundamente documentada y completamente comprobada de una organización creíble de recolección de noticias. Tal vez Le Monde, el Wall Street Journal, o Süddeutsche Zeitung.

La segunda es una historia falsa o engañosa. Pero el artículo está diseñado para imitar el contenido de una redacción creíble, desde su titular hasta su difusión.

¿Cómo van los dos artículos?

El primer artículo, diseñado para informar, recibe una atención limitada. El segundo artículo, diseñado para ser viral, acumula interacciones. Explota las tendencias cognitivas, repeticiones de creencias y burbujas de filtros algorítmicos. Se filtra a través de Internet, difundiendo la desinformación.

Este no es un escenario hipotético, está sucediendo ahora en los Estados Unidos, en Gran Bretaña, en Francia, en Alemania y más allá. El Papa no apoyó a un candidato presidencial de Estados Unidos, ni las notas de la India de 2000 rupias contienen un dispositivo de seguimiento. Pero el contenido falsificado, los titulares engañosos y el falso contexto convencieron a millones de usuarios de Internet de lo contrario.

El impacto de la desinformación en nuestra sociedad es uno de los temas más divisivos, tensos e importantes de nuestros días. La información errónea agota la transparencia y siembra la discordia, erosiona la participación y la confianza, y sustrae el beneficio público de la web. En resumen: hace que Internet sea menos saludable. Como resultado, la capacidad de Internet para impulsar la sociedad democrática sufre mucho.

Por eso estamos lanzando MITI. Invertimos en personas, programas y proyectos que frenan la desinformación a través de Internet.

¿Por qué Mozilla? La propagación de la desinformación viola casi todos los principios del Manifiesto de Mozilla, nuestra doctrina de guía. Mozilla tiene una larga historia de poner la comunidad y los principios en primer lugar, y dedicar recursos a cuestiones urgentes, nuestro navegador Firefox es sólo un ejemplo. Mozilla se compromete a construir la tolerancia en lugar del odio, y la construcción de tecnología que puede proteger a los individuos y la web.

Por lo tanto, nos basamos en la profundidad y amplitud únicas de la Red Mozilla, desde periodistas y tecnólogos a diseñadores de políticas y científicos, para crear productos funcionales, investigaciones y soluciones basadas en la comunidad.

La desinformación es un problema complejo con raíces en la tecnología, la ciencia cognitiva, la economía y la alfabetización. Por lo tanto, la Iniciativa de Información de Confianza de Mozilla se centrará en cuatro áreas:

Producto

El equipo Open Innovation de Mozilla trabajará con tecnólogos y artistas de ideas afines para desarrollar tecnología que combata la desinformación.

Mozilla se asociará con organizaciones de medios globales para hacer esto, y también duplicará el trabajo de productos existentes como Pocket, Focus y Coral. Coral es un proyecto de Mozilla que construye herramientas de código abierto para hacer que el periodismo digital sea más inclusivo y atractivo.

Alfabetismo

No podemos resolver la desinformación sólo con la tecnología: también necesitamos educar y capacitar a los usuarios de Internet, así como a las principales iniciativas innovadoras de alfabetización.

Mozilla desarrollará un plan de estudios de alfabetización web que aborde la desinformación y continuará invirtiendo en proyectos existentes como el kit de enseñanza Mission:Information.

Investigación

La desinformación en la era digital es un fenómeno relativamente nuevo. Para solucionar un problema tan peliagudo, primero debemos entenderlo completamente.

A finales de este año, Mozilla publicará una investigación sobre cómo la desinformación afecta las experiencias de los usuarios en línea. Nos basaremos en un conjunto de datos de navegación a nivel de usuario recopilados durante las elecciones de 2016 en los Estados Unidos.

Intervenciones creativas

Mozilla trabajará y financiará los lanzamientos de los tecnólogos que están combatiendo la desinformación usando varios medios, incluyendo la realidad virtual y la realidad aumentada. Es una oportunidad para aplicar la tecnología emergente a una de las cuestiones más urgentes de hoy.

Imagina: una aplicación web de realidad aumentada que utiliza la visualización de datos para investigar el impacto de la información errónea en la salud de Internet. O, una experiencia de realidad virtual que lleva a los usuarios a través de la historia de la desinformación en Internet.

Mozilla también apoyará eventos clave en este espacio, como Media Party Argentina, el Simposio de Computación + Periodismo, la Asociación de Noticias en Línea, la cumbre 22 × 20 y un MisinfoCon en Londres como parte de MozFest. (Para obtener más información sobre MozFest, el evento anual de Mozilla dedicado a la salud en Internet, visita mozillafestival.org).

Esperamos escuchar y trabajar con socios que compartan nuestra visión. Por favor, para participar ponte en contacto con Phillip Smith, Senior Fellow de Mozilla en Media, Misinformation & Trust, en miti@mozilla.com.

Más que nunca, necesitamos una red de personas y organizaciones dedicadas a la comprensión, y la lucha contra la desinformación en Internet. La salud de Internet, y de nuestras sociedades, depende de ello.

Artículos relacionados:

Categorías: Mozilla Hispano

WebAssembly facilitará la colaboración en los códecs de vídeo de nueva generación

Noticias de Mozilla Hispano - Mar, 15/08/2017 - 20:08

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

Michael Bebenita, ingeniero en investigación en Mozilla, publicó recientemente un artículo fascinante sobre el desarrollo de AV1, un códec de video de nueva generación. Si estás interesado en cómo se crean nuevos formatos de medios, te recomiendo mucho que leas el artículo completo.

Lo que llamó mi atención fue la discusión sobre portar el analizador de bitstream AV1 a la Web:

La entrada del analizador es normalmente pequeña (un bitstream codificado), pero la salida es muy grande. […] La solución ideal es ejecutar el analizador directamente en el navegador y por lo tanto eliminar la necesidad de descargar la salida del analizador.

¿Pero cómo hacer esto cuando el códec está escrito en C? Una opción es re-implementarlo manualmente en JavaScript y esperar que puedas continuar con los cambios de la implementación de referencia. La otra y mejor opción es reutilizar el de C directamente y compilarlo para la Web. Eso es exactamente lo que el equipo de AV1 está haciendo, con la ayuda de Emscripten.

Emscripten compila C/C++ arbitrario a JavaScript, lo que hace posible para el equipo de AV1 compilar automáticamente cada revisión de su códec a JavaScript y publicarlo para la Web. En este punto, comparar dos revisiones del códec es tan simple como compartir un enlace.

El flujo de trabajo es suficientemente rápido, pero no es tan rápido como podría serlo. Como JavaScript no soporta números enteros de 64 bits, muchas de las computaciones de AV1 tienen que padecer conversiones numéricas costosas. Especialmente, emular matemáticas de 64 bit se estima que añade hasta un 20% de penalización en el rendimiento de AV1, y ya hemos visto penalizaciones de rendimiento de hasta el 600% en otros proyectos que son directamente atribuibles a esta emulación.

Ahí es donde WebAssembly entra en juego. WebAssembly es un nuevo formato de bajo nivel para programas en la Web. Es un estándar abierto desarrollado por Mozilla, Microsoft, Google, y Apple, por lo que funcionará eventualmente en todos los navegadores. Babenita explica, “WebAssembly tiene soporte para matemáticas de 64 bit, y una vez que esté listo [el analizador bitstream AV1] cambiará a WebAssembly.”

Afortunadamente, Emscripten ya tiene soporte experimental para la compilación a WebAssemby, por lo que el flujo de trabajo de AV1 continuará siendo igual: desarrollar una única base de código en C y utilizar Emscripten para compilarlo a la Web para hacer pruebas. De esta manera, WebAssembly jugará un rol integral en el desarrollo de códecs de vídeo de nueva generación.

Aún más importante, ese flujo de trabajo representa un cambio fundamental en el desarrollo Web: el muro entre lo nativo y la Web está siendo derrumbado, y los desarrolladores serán capaces de utilizar de igual manera las mismas librerías en ambos contextos. Esto marca el final de los tediosos cambios manuales de proyectos a JavaScript y abre la puerta a una mejora de rendimiento en la Web.

Artículos relacionados:

Categorías: Mozilla Hispano

Extensiones multi-navegador, disponibles ahora en Firefox

Noticias de Mozilla Hispano - Jue, 10/08/2017 - 02:58

Esta es una traducción del artículo original publicado en el blog de Mozilla Hacks.

¡Estamos modernizando la forma en la que los desarrolladores construyen extensiones para Firefox! Lo llamamos las nuevas APIs WebExtensions, porque están escritas utilizando tecnologías Web: HTML, CSS y JavaScript. Y al igual que las tecnologías de la Web, puedes escribir un código que funcione en múltiples lugares.

Las APIs de WebExtensions están inspiradas en las APIs existentes de las extensiones de Google Chrome, y están respaldadas por Opera, Firefox y Microsoft Edge. ¡Estamos trabajando en estandarizar esas APIs existentes al igual que en la propuesta de otras nuevas! Nuestro objetivo es el crear extensiones que sean tan fáciles de compartir entre navegadores como las páginas en las que navegan, y lo suficientemente potentes como para permitir a la gente personalizar sus navegadores para adaptarlos a sus necesidades.

¿Quieres saber más? Construye WebExtensions Migra una extensión de Chrome existente

Artículos relacionados:

Categorías: Mozilla Hispano

Páginas

Subscribe to Proyecto NAVE aggregator - Mozilla Hispano