Perbedaan kinerja sangat besar saat menggunakan drawImage dengan IMG vs CANVAS

Saya mengumpulkan beberapa tes sederhana yang membuat gambar ke kanvas. Satu merender dari IMG, sementara yang lain merender dari CANVAS offscreen. Anda dapat melihat kode dan hasilnya di sini: http://jsperf.com/canvas-rendering/2

Di sebagian besar peramban, rendering dari gambar jauh lebih cepat daripada rendering dari kanvas, kecuali di Chrome, di mana situasinya terbalik. Adakah yang bisa menjelaskan alasan perbedaannya? Bagaimanapun, kami membuat data piksel yang sama ke tujuan yang sama.

OK, saya menemukan jawabannya. Hampir. Ini sebenarnya cukup jelas, dan saya merasa agak bodoh karena tidak segera menyadarinya. Saat Anda menelepon drawImage(src, 0, 0)tanpa menentukan lebar / tinggi, ia akan menarik seluruh wilayah src, yang dalam kasus ini jauh lebih besar (kanvasnya 320x420 versus img pada 185x70). Jadi dalam kasus kanvas browser melakukan lebih banyak pekerjaan, yang menjelaskan kinerja lebih lambat. Saya masih bingung dengan skor Chrome yang lebih tinggi dengan src yang lebih besar.

dest.drawImage(src, x, y) // bad
dest.drawImage(src, x, y, w, h, destX, destY, w, h) // good

Saya telah memposting versi terbaru yang menggunakan wilayah yang sama, dan perbedaannya jauh lebih dekat. http://jsperf.com/canvas-rendering/5

Saya masih tidak bisa menjelaskan mengapa ada perbedaan, tetapi sekarang cukup kecil sehingga saya tidak begitu peduli.

Chrome kemungkinan akan menggunakan akselerasi perangkat keras.

Buat kanvas 240x240 dan jalankan percobaan Anda di Chrome lalu buat kanvas 300x300 dan lakukan lagi. Kanvas yang lebih besar saya perkirakan lebih cepat karena akselerasi perangkat keras muncul setelah 256x256 dan chrome menggunakan perangkat lunak ketika ukurannya lebih kecil.

Juga layak untuk menunjukkan bahwa -webkit-transform: translateZ (0) mematikan akselerasi perangkat keras.

Saya belum menguji salah satu di atas; Saya hanya tahu ini karena salah satu insinyur chrome mengomentari bug yang saya laporkan dalam chrome ketika Anda melewati ambang perangkat keras dan perangkat lunak dengan secara dinamis mengubah ukuran kanvas dari yang lebih besar ke yang lebih kecil daripada batas 256x256 atau sebaliknya. Solusi untuk bug ini adalah mematikan akselerasi menggunakan translateZ seperti yang disebutkan di atas.

Dalam kasus saya, saya tidak mengizinkan pengguna untuk mengubah ukuran kurang dari 256x256.

Terkadang gambar mungkin dimuat ke memori GPU dan kanvas dalam memori host. Dalam hal ini ketika Anda menggambar dari gambar ke kanvas data gambar harus disalin terlebih dahulu ke memori host dan kemudian ke kanvas.

Saya memperhatikan perilaku semacam itu dengan Chrome, ketika saya sedang menulis proyek yang memuat lebih dari 100 juta piksel gambar dan kemudian membacanya sebagian ke kanvas 256x256 kecil ( http://elhigu.github.io/canvas-image-tiles/ ).

Dalam proyek itu jika saya menggambar langsung dari tag gambar ke kanvas di Chrome, memori selalu melonjak hingga ~ 1,5GB ketika menggambar dimulai dan kemudian ketika menggambar berakhir, memori dibebaskan lagi, bahkan gambar sumber 250 megapiksel itu ditampilkan sepanjang waktu di halaman.

Saya memperbaiki masalah dengan menulis gambar sekali ke kanvas besar (ukuran yang sama dengan gambar) dan kemudian menggambar kanvas yang lebih kecil dari sana (saya juga membuang gambar setelah mengubahnya menjadi kanvas).

Tidak bisa menjelaskan perbedaannya, tapi saya tidak setuju

Dan fakta bahwa setidaknya satu browser utama memiliki karakteristik kinerja yang berlawanan berarti kita perlu menerapkan dua jalur kode dalam penyaji kami. - alekop

Jika Anda melihat hasil pada js.pref perbedaan dalam krom cukup halus. Saya akan tetap dengan hanya rendering dari gambar jika memungkinkan.

Ukuran gambar adalah 185 * 70 tetapi kami membuat kanvas dengan ukuran, saya pikir ini akan membuang-buang kinerja, jadi saya mengatur ukuran kanvas offscreen sama seperti gambar. Dan perbedaannya lebih dekat.

var g_offscreenCanvas = createCanvas(185, 70);

http://jsperf.com/canvas-rendering/60