Skip to content

chrome

Native Client

Más alternativas a la creación de contenido para la web. A ver, un repaso rápido a lo más popular que tenemos ahora mismo. Por una parte está el omnipresente Flash, que se resiste a morir, sobre todo porque Google no hizo nada para matarlo en su día, aunque Adobe ahora está reculando un poco y prefiere que la gente empiece a utilizar su plataforma AIR. Por otra parte está HTML5, aunque hoy en día es complicado hacerse un desarrollo entero en JavaScript, poder se puede, pero faltan las herramientas adecuadas para hacerlo de una forma productiva, además de otras lagunas en los navegadores que tardarán un tiempo en cubrirse. IMHO, Flash hoy en día le gana a HTML5 por goleada.

Mención aparte para Unity3D, que a pesar de ser un plugin siempre ha sido bien visto por la comunidad. Y de Silverlight mejor no hablamos, aunque posiblemente deberíamos estar hablando más de él. Y por último X3D, el sucesor de VRML, que parece que va a acabar siguiendo su mismo camino de estándar caído en el olvido.

Y los experimentos de conversión de Flash a HTML5 por ahora son sólo eso, experimentos.

Native Client (NaCl) es una tecnología que implementa Chrome y que viene a ser una «sandbox» donde se permite ejecutar código nativo no seguro. El navegador ejecuta el código capturando las llamadas que interactuan con el sistema evitando que se ejecute código potencialmente malicioso. Y todo ello con sólo una pérdida de rendimiento estimada del 5% según los técnicos de Google.

Esta semana esta tecnología ha cobrado un poco de relevancia por la publicación en la Chrome Web Store de Bastion, un juego RPG muy popular. Lo he estado probando, unos diez minutos o así, y la verdad es que funciona bastante bien. Me ha sorprendido muy gratamente.

Recuerdo haber estado leyendo documentación sobre Native Client hace unos meses y me gustó por el enfoque que le estaban aplicando. Concretamente porque estaban migrando algunas librerías como la popular SDL. No trataban tanto de vender su producto, sino más bien de conseguir que fuera útil. Hasta entonces sólo me parecía un plugin más, como ActiveX, pero cuando vi ese movimiento me gustó bastante. Hay muchos desarrollos antiguos, o actuales, que podrían cobrar una nueva vida gracias a eso.

La filosofía es un poco como la de Java, un sólo código que se ejecuta en todas partes. Lo bueno es que el código en este caso puede estar escrito en C o C++, por lo que se puede reaprovechar todo lo que se tiene actualmente. Por ejemplo, recuerdo haber visto hace un tiempo un port del popular emulador DOSBox a NaCl, lo que automáticamente permitía ejecutar todas nuestras queridas viejas aplicaciones directamente en el navegador. Una locura.

js-aruco: Depurando en vivo y directo

He hecho unas modificaciones a js-aruco para poder disponer de unas cuantas imágenes intermedias que permitan ir siguiendo con más detalle lo que hace la librería por dentro en cada frame. (Recomiendo ver el vídeo a pantalla completa)



Demo online: www.inmensia.com/files/aruco/debug/debug.html

Las imágenes auxiliares muestran:
– La conversión a escala de grises
– El proceso de umbralización
– La detección de contornos
– La aproximación a polígonos
– Los polígonos candidatos
– La transformación de perspectiva
– La umbralización de los candidatos con Otsu

Y aún podría añadir algunas imágenes más, como la resultante del filtro gaussiano y la diferencia de esta con la de escala de grises que se utiliza para el proceso de umbralización, o algún tipo de información numérica, como el número de pixels contabilizados dentro de cada cuadrícula de los marcadores.

Actualizado 28/02/2012: He eliminado el uso de Flash, ahora la demo se debe ejecutar con Chrome 18 o posterior usando el flag –enable-media-stream en línea de comandos.

Nuevo Garbage Collector para V8

V8 es la máquina virtual de JavaScript que lleva implementada Chrome. El lunes el equipo de desarrollo anunció un cambio en su política de gestión del Garbage Collector (GC) para mejorar el rendimiento de las aplicaciones interactivas, es decir, aplicaciones web y juegos HTML5 sobre todo.

Antes detenían completamente la ejecución de los programas hasta que el GC hubiera terminado de procesar «toda» la memoria, por lo que el tiempo de proceso del GC dependía del tamaño de la memoria ocupada. Ahora lo hacen de forma incremental, es decir, sólo una parte de la memoria cada vez, evitando así tener que parar los procesos por mucho tiempo y proporcionando una mejor interactividad.

Han creado una prueba de stress para poder medir de una forma objetiva el rendimiento. Con la versión actual de Chrome (16.0.912.41) he obtenido los siguientes resultados:

8000/320 16(max = 236) ms 3307 frames
Score 3
  0 –  10 ms =>  129
 10 –  20 ms => 3028
 20 –  30 ms =>    4
 30 –  40 ms =>   88
 40 –  50 ms =>   20
 50 –  60 ms =>    1
 80 –  90 ms =>    1
110 – 120 ms =>    1
120 – 130 ms =>   18
220 – 230 ms =>    1
230 – 240 ms =>   16

Con la versión Canary (17.0.949.0), es decir, la versión que se encuentra actualmente en desarrollo, he obtenido los siguientes resultados:

8000/320 16(max = 114) ms 3516 frames
Score 36
  0 –  10 ms =>    9
 10 –  20 ms => 3314
 20 –  30 ms =>   13
 30 –  40 ms =>  163
 40 –  50 ms =>    4
 50 –  60 ms =>    2
 60 –  70 ms =>    2
 70 –  80 ms =>    2
 80 –  90 ms =>    3
 90 – 100 ms =>    2
100 – 110 ms =>    1
110 – 120 ms =>    1

Lo que han intentado con esta mejora es reducir los picos de actividad del GC durante los cuales se detiene completamente la ejecución de los programas en JavaScript. Y como se observa, tras el cambio, el tiempo máximo por frame se ha reducido a la mitad, de 236 a 114 milisegundos. Los números «grandes» tienden a concentrarse en los intervalos «pequeños». Lo que quiere decir que los programas, y por ende los usuarios, obtendrán un mejor tiempo de respuesta que antes, en vez de estar esperando a que termine su labor el GC.

Curiosamente con la versión actual de Firefox (8.0.1) la prueba de stress va mucho mejor para un tiempo medio de frame prácticamente igual (16~17), son unos 10 frames que se van de tiempo en Chrome los que marcan la diferencia:

8000/320 17(max = 58) ms 3534 frames
Score 213
 0 – 10 ms =>    3
10 – 20 ms => 3516
20 – 30 ms =>    2
40 – 50 ms =>    1
50 – 60 ms =>   12

Lo del funcionamiento del GC era algo que ya había detectado cuando estuve haciendo análisis de rendimiento de mis proyectos en JavaScript. Aunque como siempre no se puede esperar la solución perfecta, todo tiene sus ventajas e inconvenientes. Al menos parece que con la nueva versión de V8 la batería de pruebas (versión 6) funciona del orden de un 5% mejor en mi ordenador con la nueva versión de Chrome, y un 50% peor con Firefox.

getUserMedia

Opera lanzó hace unas semanas un build especial de su navegador que habilitaba el uso de la función getUserMedia de JavaScript. Esta función permite acceder a la webcam directamente desde JavaScript de forma nativa. He creado una nueva demo de js-aruco, mi detector de marcadores de realidad aumentada, usando esta versión para conseguir que todo el proceso sea 100% JavaScript evitando Flash para la captura de la webcam.



Demo online: www.inmensia.com/files/aruco/getusermedia/getusermedia.html

Para que la demo funcione hay que realizar dos pasos:

1) Instalar la versión especial del navegador de Opera que se encuentra en el siguiente enlace:
http://labs.opera.com/news/2011/10/19/

2) Permitir el acceso del navegador a la webcam a través de las opciones de configuración a través del siguiente enlace:
opera:config#SecurityPrefs|AllowCameraToCanvasCopy

Por motivos de seguridad, el navegador debería pedir permiso a los usuarios antes de acceder a la webcam, pero este funcionamiento no está todavía implementado. Lo que si está desarrollado es que no se pueda acceder por código. Si se intenta acceder con la función getImageData al contenido del canvas se produce una excepción de seguridad.

Actualizado 28/02/2012: Ahora también se puede ejecutar con Chrome 18 o posterior usando el flag –enable-media-stream en línea de comandos.

Antialias en Firefox 4

Tenía pendiente hacer una prueba en la nueva versión de Firefox para comparar el rendimiento de js-openctm con respecto a Chrome, y la verdad es que el resultado ha sido bastante decepcionante. Firefox tarda del orden de cuatro veces más con los modelos grandes (1 millón y medio de polígonos). Y lo que es peor, aún no tiene implementado antialias. En la imagen puede verse un modelo renderizado con WebGL en Chrome (izquierda) y Firefox (derecha).

WebGL - Antialias
Los característicos «dientes de sierra» que aparecen debido a la falta de antialias son bastante evidentes en el render de Firefox, aun cuando se supone que debería estar activado por defecto según se indica en la especificaciones de WebGL.

He tratado de activarlo por software, a través de los «hints» que se le pueden pasar como parámetro a la hora de obtener el contexto, pero no ha servido para nada.

canvas.getContext("webgl", {antialias:true});

Buscando por Internet me he encontrado una respuesta del equipo de Firefox a este comportamiento. Y viene a decir que realmente lo del antialias no es obligatorio, sólo eso, un «hint». Que por ahora no lo tienen implementado, y que no les parece prioritario.

Lo que si funciona es decirle a Chrome que desactive el antialias para que se vea igual de mal que en Firefox. Aunque no resulta de mucha utilidad, sólo para constatar que tiene implementada la gestión del antialias.