Originalmente visto en: The Shoze Blog – brorwser wars
Tags » ‘Firefox’
Haciendo uso de las nuevas características presentes en las beta de Firefox 4 (Data Audio API), Greg Jopa desarrollo una simple aplicación que permite ejecutar tabs (tablaturas) directamente desde el browser (en este caso y por el momento, unicamente Firefox 4).
La magia resulta complemento de la generacion y uso de las tablaturas en formato MusicXML, que parsea a un simple javascript con las notas a ejecutar.
//... playNote(notes.C, 4, 1); playNote(notes.C, 4, 1); playNote(notes.G, 4, 1); playNote(notes.G, 4, 1); //...
Para los curiosos (y los músicos javascripteros también), la magia de las notas hecha script:
function playNote(distanceFreq, octave, length) {
// calculate frequency
var frequency = 440 * Math.pow(2,((octave-4) * 12 + distanceFreq)/12);
var start = Math.ceil(sampleRate * index * 60 / tempo);
// -100ms pause at the end
var end = Math.floor(sampleRate * ((index + length) * 60 / tempo - 0.1) );
var k = 2* Math.PI * frequency / sampleRate;
for (var i = start; i <= end; i++) {
buffer[i] = Math.sin(k * i);
}
index += length;
}
Leer más:
- HTML5 Guitar Tab Player (Mozilla)
- Guitar Tab Player with the Firefox Audio Data API (Greg Jopa)
- Codigo fuente (GitHub – Greg Jopa)
Prácticamente todo el mundo con PC sabe lo que es un browser y como utilizarlo, pero como sucede con todo, existe un gran desconocimiento de las formas y comportamiento de los mismos.
Este post tiene como humilde objetivo introducir en los conceptos básicos de dos de los componentes más críticos de los browsers en cuanto a experiencia generada; estos son el motor gráfico y el interprete JavaScript.
A modo de disclaimer: No incluyo a Opera por dos motivos. El primero es la poca participación que tiene en el mercado (1.93% según wikipedia al día de la fecha), y el segundo es que no tengo suficiente conocimiento del mismo e implicaría bastante más investigación que el resto.
Motor gráfico (Layout engine)
Cualquier browser (de primera línea, por así decirlo), posee un motor gráfico encargado de renderizar los archivos html (entre otros, dependiendo del navegador en cuestión). La interpretación que hacen debería respetar la especificación correspondiente*, con agregados particulares como suelen ser la libre interpretación de casos no previstos por la especificación o inclusive errados sintácticamente.
*Los motores gráficos listados pueden no ser estrictamente “motores gráficos”, pudiendo cumplir roles adicionales a los detallados (como ser manejo de historial, soporte DOM, etc).
El renderizado de los browsers (y su velocidad al realizarlo) se puede percibir al:
- Cargar un sitio, donde se produce un renderizado completo, lo que implica generar la estructura en memoria (render) y su posterior “dibujo” en pantalla (draw).
- Modificar la estructura del árbol DOM o la geometría de uno o más nodos. En este caso se debe revalidar la estructura generada (parcial o totalmente, dependiendo de la modificación). Esta acción se denomina reflow.
- Modificar el estilo o geometría de uno o más nodos. Se debe actualizar la visualización de la parte modificada. Esta acción se denomina repaint (o redraw).
Sabiendo esto, vamos a conocer a los sospechosos de siempre.
Microsoft: Trident
Internet Explorer usa Trident como motor gráfico desde la versión 4, con obvios progresos desde ese entonces. De los browsers populares, este es sin duda el menos avanzado (sin contar que corre únicamente sobre Windows).
Los problemas de renderizado* y box model que tuvo y tiene lo ponen muy detrás de los competidores. Gran ejemplo de esto es la dificultad que genera desarrollar un sitio compatible con IE6 e inclusive IE7.
Obviamente, esperamos (y rogamos) que IE9 sea ciertamente un cambio de aire al respecto. Aparentemente IE10 va a reemplazar Trident con Linx.
*Particularmente fui víctima de un memory leak utilizando background transparente, lo cual descubrí después de culpar y refactorear todo el javascript del site.
Mozilla: Gecko
Mozilla usa Gecko (originalmente denominado NGLayout) para sus navegadores, ciertamente más poderoso que Trident. Está escrito en C++ y es multiplataforma.
Como adicional cabe destacar que tiene soporte nativo para renderizar archivos XUL (lenguaje de interfaz propio de Mozilla).
A los valientes, los invito a probar SeaMonkey, una “internet-suite” que utiliza Gecko para el render web.
Apple + Google: WebKit
Chrome y Safari (entre otros) utilizan WebKit, que surge como fork de KHTML (motor gráfico para el navegador de KDE, Konkeror). Hablando con propiedad, si bien ambos utilizan este motor, no lo hacen con todos los componentes.
Como se verá más adelante Chrome utiliza WebCore (parte específicamente dedicada al render dentro de WebKit) pero no JavaScriptCore, al cual reemplaza con un intérprete propio.
Este motor gráfico es usado también por Adobe para su plataforma Air.
Dato curioso, el navegador Lunascape utiliza tres motores gráficos distintos (Trident, Gecko y WebKit), permitiendo alternar entre ellos.
Interprete JavaScript (JavaScript engine)
Por otra parte, otro componente (obviamente crítico) es el interprete Javascript, del cual depende obviamente la ejecución de los scripts. En este aspecto varían las implementaciones de browser a browser, así como también las optimizaciones realizadas.
Estos intérpretes están recibiendo mucha atención hoy en día, siendo el rendimiento de los mismos un factor crítico a la hora de promocionar los productos.
Microsoft: JScript, Chakra y la turba iracunda
Cualquier persona que se maneje mínimamente en el tema del desarrollo web sabe sobradamente lo odioso que se tornan las cosas al incluir los productos de Microsoft en la ecuación.
Obviamente esto no cambia a la hora de hablar de Internet Explorer y su (¿libre?) interpretación de JavaScript. En principio, ellos no interpretan JavaScript como está propuesto por el estándar (!), sino JScript, que representa un subset de funcionalidad JavaScript en conjunto de algunas extensiones propietarias*.
*Hay que reconocer sin embargo, que algunas de esas extensiones originalmente propietarias son muy exitosas hoy en día, siendo la más reconocible de las mismas las XMLHttpRequest(vulgarmente hablando, Ajax).
Mozilla: SpiderMonkey
Mozilla utiliza SpiderMonkey (que viene de la época de Netscape), escrito en C. A este motor se agregaron como componentes de optimización TraceMonkey (FF3.5) y JägerMonkey (FF4.0). Las optimizaciones realizadas van desde pre compilación (se optimiza el código al evaluarlo) hasta compilar en tiempo de ejecución porciones de código críticas (como ser el código interno de un loop).
Proyecto hermano de SpiderMonkey es Rhino, motor escrito en Java, en el cual se basan los proyectos SSJ Narwhal y RingoJS.
Google: V8
Google presentó su navegador (Chrome) con un poderoso motor Javascript denominado V8. A diferencia de SpiderMonkey, V8 está escrito en C++. Obviamente también presenta un conjunto de optimizaciones, siendo la más importante compilar el código Javascript a código nativo además de usar la técnica de inline caching.
Este motor es artífice del hype actual que existe con respecto a la velocidad de ejecución, desde su salida, todos los browsers del mercado tratan de seguirle el paso a Google con obvio beneficio para los usuarios.
Al igual que ocurre con Rhino, este intérprete es utilizado por (al menos) un proyecto SSJ, en este caso se trata de Node, sin duda alguna el de más renombre actualmente.
Apple: JavaScriptCore y SquirrelFish
Safari utiliza por obvios motivos el intérprete JavaScript propio de WebKit, con las también obvias mejoras recibidas.
En este caso, el esfuerzo de los muchachos de WebKit se canaliza en SquirrelFish, que posteriormente evoluciona a SquirrelFish Extreme (SFX, mejor conocido Nitro) que aplica la ya mencionada receta de traducir JavaScript a código nativo con su consecuente mejora de performance.
Leer más:
- Rendering: repaint, reflow/relayout, restyle (Stoyan Stefanov)
- Gecko (Mozilla)
- The New JavaScript Engine in Internet Explorer 9 (Blogs msdn)
- an overview of TraceMonkey (Mozilla)
- improving JavaScript performance with JägerMonkey (Mozilla)
- Lunascape
Imagen de Trident tomada de: http://blogs.sitepoint.com/2010/04/01/microsoft-drop-trident-from-internet-explorer/
Debido a la reciente publicación de vulnerabilidades del protocolo las releases más recientes de Opera y Firefox tienen deshabilitado el soporte para el uso de WebSockets.
Estas vulnerabilidades se dieron a conocer mediante un paper publicado por Adam Barth, en el cual explica la posiblidad de atacar el protocolo modificando el caché existente entre el browser y la “nube”.
The protocol vulnerabilities also affect Java and Flash solutions. In a web environment that could for example mean that a widely used JavaScript file – like Google analytics – could be replaced on a cache you go through with a malware file
Esta situación muestra la realidad que se vive hoy en día. En la que en medio de la gran expectativa que existe en torno a la implementación de características HTML5 no se puede obviar la falta de madurez que existe en su especificación.
Leer más:
