A partir de crbug.com/73313, Chrome 13 y FF5 admiten el envío de un ArrayBuffer (o array escrito) desde y hacia un trabajador web. Por ejemplo:
worker.js
self.onmessage = function(e) {
var uInt8Array = e.data;
postMessage("Inside worker.js: uInt8Array.toString() = " + uInt8Array.toString());
postMessage("Inside worker.js: uInt8Array.byteLength = " + uInt8Array.byteLength);
};
main.html
var uInt8Array = new Uint8Array(new ArrayBuffer(10));
for (var i = 0; i < uInt8Array.length; ++i) {
uInt8Array[i] = i * 2; // [0, 2, 4, 6, 8,...]
}
console.log('uInt8Array.toString() = ' + uInt8Array.toString());
console.log('uInt8Array.byteLength = ' + uInt8Array.byteLength);
worker.postMessage(uInt8Array);
¿Por qué es tan emocionante? ¡Datos binarios!
En lugar de que el navegador serialice tus datos postMessage() en un objeto JSON, usa el algoritmo de clonación estructurado para copiar el ArrayBuffer en el contexto del trabajador y viceversa. Esto abre un potencial real para los trabajadores que no habíamos visto antes. Es decir, poder pasar datos binarios fácilmente entre la app principal y el subproceso de trabajo.
La E/S de array escrito hace que la manipulación intensa de imágenes, el procesamiento de sonido y los cálculos pesados de WebGL sean mucho más factibles. Por ejemplo, se podría leer un archivo como un búfer de array o recuperar un blob con XHR2 y pasar el resultado directamente a un trabajador. Ya no es necesario codificar los datos en Base64.
En mi opinión, esta es una de esas pequeñas observaciones que los trabajadores deberían haber incluido desde el principio. Tiene sentido.