Chrome

Temas: Chrome
Juan Mellado, 14 Diciembre, 2011 - 20:35

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.

Juan Mellado, 7 Diciembre, 2011 - 15:42

Un experimento rápido y un poco tonto con js-aruco usando las sombras como marcadores de realidad aumentada.


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

Juan Mellado, 28 Noviembre, 2011 - 13:15

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.

Juan Mellado, 25 Noviembre, 2011 - 12:38

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.

Juan Mellado, 23 Noviembre, 2011 - 17:18

DartDart es el nombre de un nuevo lenguaje de programación creado por Google que se plantea como una alternativa de futuro a JavaScript. Siempre he pensado que el atributo "type" de la etiqueta "script" estaba para algo más que tomar un valor por defecto, y parece que al fin alguien se lo ha tomado en serio.

¿Pero realmente necesitamos un nuevo lenguaje de programación? Pues como siempre la respuesta depende de como le duela a cada uno. Para validar formularios, realizar efectos o hacer alguna que otra librería independiente tenemos más que suficiente con JavaScript. Pero para desarrollos que impliquen una mayor complejidad, y sobre bastante miles de líneas de código, entonces estamos necesitando claramente otro lenguaje. En particular con las características deseables de un lenguaje orientado a objetos, en vez de estar siempre tratando de emular estas características en JavaScript. Y todo esto naturalmente partiendo de la base de que a futuro sigamos queriendo ejecutar (mucho) código en el cliente.

Cuestiones filosóficas aparte, siendo muy simplista, la idea es que Dart recupera para la web las palabras reservadas interface y class, con sus constructores, métodos y variables de instancia. Pero eso es sólo una pequeña parte, claro. También proporciona un punto de entrada a las aplicaciones a través de una clásica función main, la posibilidad de importar librerías con #import, incluir código con source, y colecciones que pueden tiparse como los templates de C++ o los generics de Java. Suena todo bastante familiar, ¿no?

main() {
  print('Hello, Dart!');
}

Dart es un lenguaje orientado a objetos basado en clases que soporta herencia simple, no múltiple, y que encapsula el código de forma modular en unidades a las que llama librerías. Proporciona mecanismos para declarar elementos públicos y privados, aunque curiosamente distinguidos por la nomenclatura de su nombre, no por un atributo modificador. Si empieza por "_" entonces es privado. Además soporta la concurrencia mediante un mecanismo propio de ejecución aislada (isolation) con intercambio de mensajes, sin memoria compartida. Y permite realizar una programación mixta en cuanto a comprobación de tipos se refiere. Pudiendo realizarse una versión inicial débilmente tipada e ir haciéndola más fuerte a medida que avanza el desarrollo. Pueden consultarse todos los detalles en el borrador actual que contiene las especificaciones del lenguaje.

Para probar Dart a día de hoy hay dos formas:

1) Utilizar el Dartboard, una pequeña aplicación web con un cuadro de texto donde se puede introducir código, compilarlo y ejecutarlo. Evidentemente el código se compila y ejecuta en un servidor remoto.

2) Utilizar el Dart Editor, una aplicación de escritorio basada en Eclipse que incorpora todas las características propias de este conocido entorno de desarrollo. En este caso el código se compila a JavaScript y se puede ejecutar desde una página HTML ordinaria directamente desde el navegador. Esta opción es similar a GWT, que acepta código en Java y genera JavaScript.

Por su parte, a futuro Dart se podrá ejecutar de dos formas:

1) Mediante un nuevo tipo MIME "application/dart" que se ejecutará de forma nativa en el navegador, de forma similar a como actualmente se ejecuta el código "application/javascript".

2) Mediante una máquina virtual en un PC local. Algo que en realidad ya puede hacerse hoy en día gracias a las herramientas de líneas de comandos ya disponibles.

Naturalmente hoy en día un lenguaje no es nada si no viene acompañado de unas buenas librerías, máxime si su ejecución ha de realizarse en un navegador donde se dispone de APIs ya establecidos. Dart en ese aspecto apenas tiene dos librerías básicas, una core y otra dom. La librería de acceso a DOM está lo suficientemente desarrollada para manipular una página web de forma dinámica, permitiendo ya actualmente acceso a los objetos de tipo canvas por ejemplo.

#library('example');
#import('dart:dom');

main() {
  new Example();
}

class Example {
  CanvasRenderingContext2D ctx;

  Example() {
    var doc = window.document;
    HTMLCanvasElement canvas = doc.getElementById("canvas");
    ctx = canvas.getContext("2d");

    render();
  }
 
  void render() {
    ctx.clearRect(0, 0, 800, 600);
...
  }
}

He estado probando el Dart Editor y compilando los ejemplos. Iba a subir uno de ellos a la web, pero finalmente he desistido porque la versión actual genera como resultado de la compilación ficheros JavaScript de varios megas, y no merece la pena.

¿Sobrevivirá este lenguaje y se popularizará? Pues no tengo ni idea. A priori resulta difícil aceptar que el resto de navegadores vaya a adoptar una especificación muy concreta de Google, y mucho menos hacer un desarrollo propio para soportarlo, pero peores cosas se han visto. La gran ventaja con la que cuenta Google en este sentido es que Dart es un proyecto de código abierto. En cualquier caso no es el primer intento por parte de Google de crear un nuevo lenguaje de programación, ahí está Go por ejemplo, cuya primera versión definitiva está prevista que aparezca el año que viene. El tiempo dirá.