Pourquoi putImageData est-il si lent ?

Question

Je travaille avec une toile relativement grande où sont dessinées diverses choses (complexes). Je veux ensuite sauvegarder l'état du Canvas, afin de pouvoir le réinitialiser rapidement à l'état actuel à un moment ultérieur. Pour cela, j'utilise getImageData et je stocke les données dans une variable. Je dessine ensuite d'autres éléments sur le canevas et je remettrai plus tard le canevas dans l'état où il était lorsque j'ai sauvegardé son état, en utilisant putImageData.

Cependant, il s'avère que putImageData est très lent. En fait, il est plus lent que le simple fait de redessiner l'intégralité du Canvas à partir de zéro, ce qui implique plusieurs drawImage couvrant la majeure partie de la surface, et plus de 40 000 opérations lineTo suivies de traits et de remplissages.

Redessiner le canevas d'environ 2000 x 5000 pixels à partir de zéro prend environ 170 ms, alors que l'utilisation de putImageData prend 240 ms. Pourquoi putImageData est-il si lent par rapport au redessin du canevas, bien que le redessin du canevas implique le remplissage de presque tout le canevas avec drawImage et ensuite le remplissage d'environ 50% du canevas avec des polygones utilisant lineTo, stroke et fill. En gros, chaque pixel est touché au moins une fois lors du redessin.

Parce que drawImage semble être beaucoup plus rapide que putImageData (après tout, la partie drawImage du redessin du canevas prend moins de 30 ms). J'ai décidé d'essayer de sauvegarder l'état du canevas sans utiliser getImageData, mais en utilisant plutôt canvas.toDataURL et en créant ensuite une image à partir de l'URL des données que je collerais dans drawImage pour la dessiner sur le canevas. Il s'avère que cette procédure est beaucoup plus rapide et ne prend que 35 ms environ.

Alors pourquoi putImageData est-il tellement plus lent que les autres solutions (utilisation de getDataURL ou simple redécoupage) ? Comment pourrais-je accélérer davantage les choses ? Existe-t-il et si oui, quelle est en général la meilleure façon de stocker l'état d'un canevas ?

(Tous les chiffres sont mesurés à l'aide de Firebug depuis Firefox).

Answer 1

Juste une petite mise à jour sur la meilleure façon de procéder. J'ai en fait écrit ma thèse de licence sur ECMAScript et HTML5 Canvas haute performance (pdf, allemand ; mot de passe : stackoverflow), j'ai donc acquis une certaine expertise sur ce sujet. La meilleure solution consiste clairement à utiliser plusieurs éléments de canevas. Dessiner d'un canvas sur un autre canvas est aussi rapide que de dessiner une image arbitraire sur un canvas. Ainsi, "stocker" l'état d'un canevas est aussi rapide que de le restaurer plus tard en utilisant deux éléments de canevas.

Ce testcase jsPerf montre très clairement les différentes approches, leurs avantages et leurs inconvénients.

Par souci d'exhaustivité, voici comment vous devez procéder. devrait faites-le :

// setup
var buffer = document.createElement('canvas');
buffer.width = canvas.width;
buffer.height = canvas.height;

// save
buffer.getContext('2d').drawImage(canvas, 0, 0);

// restore
canvas.getContext('2d').drawImage(buffer, 0, 0);

Cette solution est, selon le navigateur, jusqu'à 5000x plus rapide que celle qui obtient les upvotes.

Answer 2

Dans Firefox 3.6.8, j'ai pu contourner la lenteur de putImageData en utilisant toDataUrl/drawImage à la place. Pour moi, cela fonctionne assez rapidement pour que je puisse l'appeler lors du traitement d'un événement de déplacement de souris :

Pour économiser :

savedImage = new Image()
savedImage.src = canvas.toDataURL("image/png")

Le pour restaurer :

ctx = canvas.getContext('2d')
ctx.drawImage(savedImage,0,0)

Answer 3

Tout d'abord, vous dites que vous effectuez des mesures avec Firebug. En fait, je trouve que Firebug ralentit considérablement l'exécution des JS, donc il se peut que vous n'obteniez pas de bons chiffres pour les performances.

Quant à putImageData je pense que c'est parce que la fonction prend un grand tableau JS contenant plusieurs Number qui doivent tous être vérifiés pour la plage (0..255) et copiés dans un tampon de toile natif.

Peut-être qu'une fois que les types ByteArray de WebGL seront disponibles, ce genre de choses pourra être fait plus rapidement.

Il semble étrange que le décodage et la décompression des données en base64 (avec l'URL des données PNG) soient plus rapides, mais cela n'appelle qu'une seule fonction JS avec une seule chaîne JS, ce qui signifie que l'on utilise principalement du code et des types natifs.

Answer 4

Cela s'explique probablement par le fait que les navigateurs modernes utilisent l'accélération matérielle pour <canvas> éléments, et getImageData() / putImageData() nécessitent le transfert de données d'image de la carte graphique vers l'hôte ou vice versa. Ce qui est notoirement lent.

L'utilisation de deux toiles sera plus rapide car toutes les données restent sur la carte graphique.