Depuis crbug.com/73313, Chrome 13 et FF5 permettent d'envoyer un ArrayBuffer (ou un tableau typé) à/depuis un Web Worker. Exemple :
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);
Pourquoi est-ce intéressant ?...Les données binaires !
Au lieu de sérialiser vos données postMessage() dans un objet JSON, le navigateur utilise l'algorithme de clonage structuré pour copier le ArrayBuffer dans le contexte du worker, et inversement. Cela ouvre un potentiel réel pour les travailleurs, qui n'avait jamais été envisagé auparavant. Autrement dit, vous pouvez facilement transmettre des données binaires entre l'application principale et le thread de travail.
Les E/S d'un tableau typé rendent la manipulation intense des images, le traitement du son et les calculs WebGL lourds beaucoup plus réalisables. Par exemple, vous pouvez lire un fichier en tant que tampon de tableau ou récupérer un blob à l'aide de XHR2 et transmettre le résultat directement à un worker. Plus besoin d'encoder les données en base64 :)
À mon avis, il s'agit de l'un de ces détails que les travailleurs auraient dû inclure dès le départ. C'est tout simplement logique.