Tại sao putImageData lại quá chậm?

Question

Tôi đang làm việc với một Canvas tương đối lớn có nhiều thứ phức tạp khác nhau được vẽ. Sau đó tôi muốn lưu trạng thái Canvas, vì vậy tôi có thể nhanh chóng đặt lại trạng thái của nó ở trạng thái hiện tại. Tôi sử dụng getImageData cho điều này và lưu trữ dữ liệu trong một biến. Sau đó, tôi vẽ thêm một số nội dung vào canvas và sau đó sẽ đặt lại Canvas thành vị trí khi tôi lưu trạng thái của nó, sử dụng putImageData.

Tuy nhiên, hóa ra là putImageData rất chậm. Infact, nó là chậm hơn so với chỉ vẽ lại toàn bộ Canvas từ đầu, trong đó bao gồm một số drawImage bao gồm hầu hết các bề mặt, và hơn 40.000 lineTo hoạt động theo sau bởi đột quỵ và điền vào.

Vẽ lại canvas khoảng 2000 x 5000 pixel từ đầu mất ~ 170ms, sử dụng putImageData mặc dù mất 240ms khổng lồ. Tại sao putImageData quá chậm so với vẽ lại canvas, mặc dù vẽ lại canvas bao gồm việc lấp đầy toàn bộ canvas bằng drawImage và sau đó điền lại khoảng 50% canvas với đa giác bằng lineTo, stroke và fill. Vì vậy, cơ bản mỗi ist điểm ảnh duy nhất chạm ít nhất một lần khi vẽ lại.

Bởi vì drawImage có vẻ nhanh hơn rất nhiều sau đó putImageData (sau khi tất cả, phần drawImage của vẽ lại canvas mất ít hơn 30 ms). Tôi quyết định cố gắng lưu trạng thái của canvas không sử dụng getImageData, nhưng thay vì sử dụng canvas.toDataURL và sau đó tạo một Image từ URL dữ liệu mà tôi sẽ dính vào drawImage để vẽ nó vào khung vẽ. Hóa ra toàn bộ quy trình này nhanh hơn nhiều và chỉ mất khoảng 35ms để hoàn thành.

Vậy tại sao putImageData chậm hơn rất nhiều thì các lựa chọn thay thế (sử dụng getDataURL hoặc vẽ lại đơn giản)? Làm thế nào tôi có thể tăng tốc độ hơn nữa? Có và nếu, nói chung cách tốt nhất để lưu trữ trạng thái của canvas là gì?

(Tất cả các số được đo bằng Firebug từ trong Firefox)

Answer 1

Chỉ cần một cập nhật nhỏ về những gì là tốt nhất cách là để làm điều này. Tôi thực sự đã viết Luận văn Cử nhân của tôi trên High Performance ECMAScript and HTML5 Canvas (pdf, tiếng Đức), vì vậy tôi đã tập hợp một số chuyên môn về chủ đề này ngay bây giờ. Giải pháp rõ ràng nhất là sử dụng nhiều phần tử canvas. Vẽ từ một khung hình lên một khung hình khác cũng nhanh như vẽ một hình ảnh đơn phương vào khung vẽ.Do đó "lưu trữ" trạng thái của canvas chỉ nhanh như khôi phục lại sau này khi sử dụng hai phần tử canvas.

This jsPerf testcase cho thấy các cách tiếp cận khác nhau cũng như lợi ích và nhược điểm của chúng rất rõ ràng.

Chỉ cần cho đầy đủ, ở đây như thế nào bạn thực sự nên làm điều đó:

// 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); 

Giải pháp này là, tùy thuộc vào trình duyệt, lên đến 5000x nhanh hơn so với một nhận upvotes.

Answer 2

Trước hết bạn nói bạn đang đo bằng Firebug. Tôi thực sự thấy rằng Firebug làm chậm JS thực hiện đáng kể, vì vậy bạn có thể không nhận được số lượng tốt cho hiệu suất.

Đối với putImageData, tôi nghi ngờ đó là vì các hàm lấy một mảng JS lớn chứa nhiều đối tượng Number, tất cả đều phải được kiểm tra phạm vi (0..255) và được sao chép vào bộ đệm gốc.

Có thể một khi các loại WebGL ByteArray có sẵn, loại điều này có thể được thực hiện nhanh hơn. Có vẻ kỳ quặc khi giải mã base64 và giải nén dữ liệu (với URL dữ liệu PNG) nhanh hơn, nhưng chỉ gọi một hàm JS với một chuỗi JS, vì vậy nó đang sử dụng hầu hết các mã và kiểu gốc.

Answer 3

Trong Firefox 3.6.8, tôi đã có thể giải quyết sự chậm trễ của putImageData bằng cách sử dụng toDataUrl/drawImage thay thế. Đối với tôi nó làm việc đủ nhanh mà tôi có thể gọi nó là trong xử lý một sự kiện MouseMove:

Để tiết kiệm:

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

Các khôi phục:

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