Pixi.js: https://pixijs.github.io/bunny-mark/ lambat

Bagaimana jika dibandingkan dengan versi sebelumnya?

Ya, sangat optimis, saya hanya sekali melihat desktop yang menangani 100k kelinci multitekstur pada 75FPS. aku juga 18 :)

Coba jalankan versi tanpa multi-texturing, ada tombol.

PIXI dioptimalkan untuk game "rata-rata", tetapi memiliki banyak parameter, dan Anda bahkan dapat menulis renderer super-optimal Anda sendiri di atas arsitektur pixi! Kami memiliki 10.000 sapi animasi (masing-masing ~ 16 paha depan), pada 30FPS stabil pada kartu video lama dan intel HD. Tahap ekstrim, penggunaan CPU sangat rendah: https://www.youtube.com/watch?v=adixpp9CK_A . Semakin banyak objek yang mengubah koordinatnya, semakin banyak CPU yang digunakan, dan dapat menangani kasus di mana semuanya bergerak setiap frame pada FPS yang memadai. Saya berharap untuk melepaskan garpu pixi itu dalam satu atau dua bulan :)

Apakah garpu ini akan digabungkan di master untuk membuat pixi hebat lagi?

Ivan apa yang Anda capai menggunakan Pixi sangat mengesankan. Nantikan untuk melihat garpu ini dan belajar darinya. :)

@ jeebus3000 Tidak, ini akan menjadi garpu produksi, itu akan membutuhkan pengetahuan mendalam tentang pixi dan webgl.

Jumlah pengaturan akan tinggi:

1. Tentukan bagaimana format animasi json Anda dikonversi ke format biner yang sesuai untuk GPU. Pra-ditentukan: hanya spritesheet, animasi flash, tulang belakang. Semua dengan pengaturan berbeda (float per instance, float per quad)
2. pixi-display++: sementara pixi memiliki Container, akan ada juga Stage, Layer dan Camera. Setiap DisplayObject memiliki Tampilan yang dimiliki oleh beberapa lapisan, dan untuk kasus ekstrim (gameofbombs.com) akan ada sejumlah tampilan per objek.
3. updateTransform() tidak dipanggil setiap frame, dan ada lebih banyak pembaruan lambat daripada di vanilla pixi. Kami tidak ingin 10k elemen dipanggil di JS saat mereka tidak bergerak melintasi peta.
4. atlas waktu nyata dan tekstur terkompresi. Saat Anda mengembangkan game, Anda harus melihat apa yang terjadi di memori video dan bagaimana atlas terbentuk. Atlas dibuat dengan pengaturan khusus dalam pengemas tekstur sebelum dikompresi dalam format yang dihasilkan.

@bigtimebuddy

Bagaimana jika dibandingkan dengan versi sebelumnya?

Ketika saya mengklik "v3.0.8" saya mendapatkan ini:

Sama untuk 3.0.9, 3.0.10.

Dilaporkan di #4023 .

Dengan 3.0.11 saya mendapatkan 6fps.

Dengan 4.0.0 dan 4.0.1 saya mendapatkan 23-24fps.

Dari sini ada regresi konstan:

Dengan 4.1.0 dan 4.1.1 saya mendapatkan 20-22fps.

Dengan 4.2.1 saya mendapatkan 19-20fps.

Dengan 4.4.4 dan 4.5.1 saya mendapatkan 16-18fps.

Saya berharap Pixi akan menjadi lebih cepat lagi.

cc @GoodBoyDigital

@ivanpopelyshev Itu mengesankan! Tetapi saya membutuhkan stok PixiJS untuk menjadi sangat cepat (dan kasus penggunaan saya sering terlihat seperti tanda kelinci).

Mungkin ada tes (yang selalu dijalankan) yang memeriksa apakah kode Pixi terbaru secepat (atau lebih cepat) dari yang tercepat dari versi sebelumnya.

Juga, mungkin tanda kelinci harus diubah untuk menggunakan kelinci kecil bertekstur tunggal jika itu membantu perf. Mungkin ada opsi untuk kelinci yang lebih besar / multi-tekstur (dan bahkan animasi sendiri) (dengan jumlah default yang jauh lebih rendah). (Opsi ini memerlukan tombol tambahan yang saat ini tidak ada.)

Jika setelah semua ini hitungan default 100000 masih terlalu optimis itu harus diubah menjadi sesuatu yang jauh lebih rendah, sehingga ketika seseorang dikirim ke tanda kelinci PixiJS (dan dijalankan dengan default) itu tidak akan membuat PixiJS terlihat buruk. Alih-alih framerate rendah saat ini, orang akan melihat 60fps yang bagus dan mulus.

@tobireif Anda hanya memiliki satu pengaturan di sana: jumlah tekstur di spriterenderer. Buat satu atlas besar 4k x 4k atau 8k x 8k dan itu akan jauh lebih baik daripada multitekstur.

Anda harus menguji pengaturan webgl yang dimiliki pengguna Anda, pengoptimalan tidak mungkin dilakukan tanpa info itu. Sebagai contoh, kita tahu bahwa 99% memiliki plugin tekstur 4k dan tekstur mengambang, dan kita sering menggunakannya, sedangkan perender vanilla pixi tidak.

Dalam kasus saya pixi seperti boilerplate untuk penyaji yang lebih baik yang cocok untuk tugas-tugas tertentu.

@ivanpopelyshev

jumlah tekstur pada spriterenderer. Buat satu atlas besar 4k x 4k atau 8k x 8k dan itu akan jauh lebih baik daripada multitekstur.

Jika itu membantu kinerja daripada yang seharusnya diimplementasikan di tanda kelinci PixiJS, bukan?

Dari versi 4.0.1 ke 4.5.1, PixiJS menjadi lebih lambat - framerate bunnymark berubah dari 23-24fps menjadi 16-18fps . Masalah itu perlu diperbaiki, dan kemudian regresi kinerja perlu dicegah untuk masa depan (misalnya menggunakan tes CI).

Dalam kasus saya pixi seperti boilerplate untuk penyaji yang lebih baik yang cocok untuk tugas-tugas tertentu.

Saya membutuhkan "vanilla PixiJS" untuk menjadi sangat berkinerja, dan saya menduga pengguna Pixi JS lainnya juga melakukannya.

Ya, kami membutuhkan satu bidang teks lagi dalam penyiapan, seperti "jumlah tekstur: ". Adapun 4.0.1-4.5.1 , saya pikir kita harus memahami dulu apakah CPU atau GPU-nya kita deoptimisasi.

@tobireif , itu poin yang bagus! Kita mungkin harus memulainya dengan sesuatu yang jauh lebih rendah - mungkin 1000? Apakah itu tweak mudah @bigtimebuddy?

Sehubungan dengan kinerja, pada dasarnya kami memperdagangkan lebih banyak fleksibilitas untuk kekuatan. Ada sedikit bias pada konten statis dalam versi pixi saat ini juga (karena kebanyakan hal cenderung tidak bergerak!)

Bunnymark berjalan jauh lebih cepat jika Anda menggunakan wadah partikel :)

Tapi ini seruan yang bagus, saat ini saya sedang mengerjakan v5, saya akan melihat apakah kita bisa mendapatkan fps itu kembali!

@ivanpopelyshev Saya kembali ke cara lama 4.0.0 cara mengikat tekstur di v5 (lebih sedikit keajaiban - saya mengembara jika itu akan membantu!)

@GoodBoyDigital yang akan membantu. pengikatan tekstur cerdas HANYA bekerja dalam hal tekstur tunggal, semua penggunaan multitekstur menyakitkan dengan itu.

Hai teman-teman, versi mana yang kami konversi ke es6? Saya tahu bahwa hit perf sedikit!

@GoodBoyDigital

Tanda kelinci adalah satu hal. Penting bahwa itu cepat, karena itu seharusnya menunjukkan bahwa Pixi cepat. Dan karena ini adalah contoh yang sempurna (yang sumbernya mungkin dipelajari dan diparafrasekan oleh orang-orang), itu harus menunjukkan semua pengoptimalan sisi pengguna-lib yang mungkin & masuk akal. Dan jumlah kelinci harus tetap menjadi angka yang mengesankan, misalnya 40000 atau 50000 (misalnya jumlah tertinggi yang menghasilkan 60fps dengan peningkatan yang disebutkan dalam tiket ini dan dengan Pixi versi 5 pada misalnya mesin saya/Ivan).

Tetapi terlepas dari kode bunnymark, Pixi sendiri harus sangat cepat, seperti yang kita semua setujui.

Saya harap Anda semua dapat mencapai dan mempertahankan kinerja yang luar biasa!

Ada sedikit bias pada konten statis dalam versi pixi saat ini juga (karena kebanyakan hal cenderung tidak bergerak!)

Setiap kali saya menggunakan Pixi, sebagian besar barang bergerak

Bunnymark berjalan jauh lebih cepat jika Anda menggunakan wadah partikel :)

Jadi kode bunnymark harus menggunakan wadah partikel, bukan?

Saat ini saya sedang mengerjakan v5, saya akan melihat apakah kita bisa mendapatkan fps itu kembali!

Besar! 👍

Saya tidak setuju dengan apa tujuan yang diasumsikan dari tanda kelinci di sini. Tujuannya adalah untuk tidak selalu menampilkan sesuatu yang berjalan pada 60fps. Kami menggunakan ini sebagai cara untuk membandingkan kinerja relatif dari rilis/dev dan sebagai uji asap. Sampai kami memiliki cara yang baik untuk membuat tolok ukur, ini adalah alat terbaik kami saat ini untuk mengukur dampak kinerja. 100000 kelinci sengaja untuk benar-benar mendorong penyaji ke tempat di mana ia akan berjuang. Jika kita ingin memamerkan seberapa cepat Pixi, ini bukan hal yang tepat untuk pekerjaan itu. Saya akan menulis sesuatu menggunakan ParticleCointainer, seperti yang disarankan ~Ivan~ Mat.

Kami tahu ada sedikit peningkatan kinerja di v4.1+ dan sebagian besar ini karena kami menulis ulang basis kode di ES6 agar lebih mudah dipelihara. Tim inti merasa bahwa pukulan kinerja kecil itu sepadan dengan pertukaran jangka panjangnya.

Saya memiliki beberapa saran tentang bagaimana kami dapat mengatasi hal ini:

• [ ] buat iklan kinerja yang lebih seksi dan ramah pengguna untuk Pixi, sebaiknya sesuatu dalam contoh. Mungkin memiliki kontrol butiran halus untuk mengaktifkan fitur. Simpan tanda kelinci sebagai alat pengujian internal saja.
• [ ] terus meningkatkan wiki untuk kiat kinerja, berpotensi menyediakan demo
• [ ] menerapkan tes pembandingan untuk Pixi, sesuatu yang konsisten untuk diukur
• [ ] memverifikasi penurunan kinerja pada versi terbaru seperti yang dinyatakan di atas

Masalah itu perlu diperbaiki, dan kemudian regresi kinerja perlu dicegah untuk masa depan

Tentu saja kita perlu meningkatkan benchmark kinerja, dan tentu saja akan sangat bagus untuk diintegrasikan ke dalam CI, dan tentu saja Pixi harus secepat mungkin. Tetapi kami juga membutuhkan orang-orang yang bersedia mengirimkan waktu untuk membantu memecahkan masalah yang sangat kompleks ini. Jika ada orang di luar sana dengan pengalaman tertentu melakukan tolok ukur kinerja di berbagai browser/perangkat keras, akan menyambut baik kontribusi di sini!

Bagaimana denganmu, @tobireif? Apakah Anda memiliki keahlian di bidang ini? Banyak kesempatan untuk meningkatkan. Selamat datang PR atau upaya di sini untuk membuat profil, untuk membuat tes yang lebih baik, untuk menemukan solusi untuk melakukan CI (Travis) dengan webgl, untuk melakukan pencarian biner pada riwayat komit mencari kontribusi kinerja negatif.

Juga, saya ingin menyatakan bahwa bunnymark ada di beberapa versi, tetapi beberapa bulan yang lalu saya meminta @bigtimebuddy untuk membantunya, saya buruk dalam membuat antarmuka :) Dia sudah menerapkan sejumlah fitur tambahan di dalamnya, saya Saya senang dengan cara itu.

Saya percaya bahwa jumlah tekstur adalah satu-satunya tugas yang penting untuk benchmark.

@bigtimebuddy

Terima kasih untuk bertanya. Saya memang memiliki pengalaman dengan pengoptimalan kinerja, tetapi sayangnya saya tidak akan dapat menemukan waktu untuk langsung mengerjakan Pixi di masa mendatang. Saya berharap kontribusi saya dalam bentuk laporan masalah ini (dan lainnya) tetap dihargai (mereka membutuhkan waktu juga ...)

Saya sekarang mengerti bahwa "pixijs.github.io/bunny-mark" dimaksudkan untuk pengujian kinerja dev-internal.

Jadi jika saya menunjukkan kepada seseorang kinerja hebat dari PixiJS (misalnya ketika merekomendasikan Pixi untuk proyek tertentu), saya akan menautkan ini http://www.goodboydigital.com/pixijs/bunnymark/ ?
(bukan https://pixijs.github.io/bunny-mark/ )
(Meskipun mungkin ada demo perf tambahan di masa depan, saya suka bunnymark, dan itu berhasil dengan sangat baik.)

(Saya pikir menampilkan kinerja kepada pengguna lib potensial adalah tujuan asli dari bunnymark pertama/sebelumnya, itu diposting di posting blog GoodBoy dll, itu bukan hanya dev-internal.)

BTW, http://www.goodboydigital.com/pixijs/bunnymark/ menggunakan ParticleContainer, tetapi versi Pixi yang lebih lama.

Sekali lagi, untuk Anda semua:

Terima kasih untuk PixiJS!

@GoodBoyDigital

Saat ini saya sedang mengerjakan v5, saya akan melihat apakah kita bisa mendapatkan fps itu kembali!

Kedengarannya bagus! Menantikannya

Mungkin ada v5 bunnymark (satu untuk menampilkan kinerja Pixi, seperti v3 bunnymark http://www.goodboydigital.com/pixijs/bunnymark_v3/ ).

Hai, yang di sana! Menutup masalah ini untuk saat ini karena tidak aktif. Jangan ragu untuk memberi tahu kami jika Anda ingin masalah ini dibuka kembali. Terima kasih 👍

Tidak masalah

Tetapi akan tetap bagus jika selalu ada bunnymark untuk masing-masing rilis terbaru, dengan satu-satunya tujuan untuk menampilkan kinerja animasi yang mengesankan dari PixiJS (sesuatu yang berbeda dari smoke-test-bunnymark yang digunakan oleh PixiJS-lib-developer) . Menautkan demo animasi yang mengesankan seperti bunnymark sangat membantu saat mempromosikan PixiJS, misalnya dalam tweet. (Bunnymark terbaru masing-masing tidak boleh lebih lambat dari yang sebelumnya / harus mendukung setidaknya jumlah kelinci yang sama pada 60fps seperti bunnymark sebelumnya. Mungkin akan menggunakan ParticleCointainer.)

Jika itu termasuk dalam lingkup proyek PixiJS, silakan buka kembali (atau kami dapat menempelkan yang di atas ke tiket baru).

Juga ada berbagai baris penting dalam tiket di sini, misalnya " terapkan tes pembandingan untuk Pixi, sesuatu yang konsisten untuk diukur" oleh Matt Karl.

Terkait: https://github.com/pixijs/pixi.js/issues/4026 .

Utas ini telah dikunci secara otomatis karena tidak ada aktivitas terbaru setelah ditutup. Silakan buka edisi baru untuk bug terkait.