Cara menghitung skor benchmark Screen Test Pro

Ini halaman metodologi. Tidak ada yang disederhanakan demi pemasaran di sini; kalau kode dan halaman ini suatu saat bertentangan, itu bug dan kami ingin mendengarnya. (Versi benchmark saat tulisan ini dibuat: 2.2.0.)

Pertanyaan yang diajukan benchmark

Kebanyakan benchmark grafis mematok beban kerja lalu mengukur frame rate Anda. Punya kami membalik itu: yang dipatok adalah target waktu frame, lalu alat mencari beban terberat yang masih bisa ditahan perangkat Anda pada target itu. Keluarannya adalah “beban stabil maksimum” per adegan — misalnya 840.000 partikel nebula — dan dari sanalah skor dibangun.

Kenapa dibalik? Karena frame rate cepat jenuh. Di mesin yang kencang, beban tetap akan mentok di angka refresh layar dan tidak memberi tahu apa pun; pertanyaan yang menarik adalah seberapa banyak lagi yang sebenarnya sanggup ditangani. Mencari langit-langitnya membuat pengukuran tetap bermakna mulai dari ponsel berumur lima tahun sampai GPU desktop, dengan adegan yang sama.

Apa yang dijalankan

Profil Standar berisi lima adegan Signature ditambah satu pembanding, masing-masing menekan sumbu yang berbeda:

Perenderan berjalan pada rasio piksel yang dibatasi (1,5×) dengan batas ukuran internal, sehingga monitor 5K dan laptop 1080p menghadapi jumlah piksel yang sebanding. Keacakan diberi seed dan langkah simulasi dipatok, jadi setiap tes pada versi tertentu mengerjakan pekerjaan yang sama.

Bagaimana kestabilan dinilai

Mesinnya tidak pernah membaca penghitung FPS. Ia mengumpulkan waktu frame dari jam animasi peramban ke dalam jendela sepanjang kira-kira 0,7–1,6 detik, lalu menuntut dua hal dari tiap jendela:

• paling banyak 5% frame boleh melewati ambang kelulusan — 17,5 ms pada layar dengan sinkronisasi adaptif; pada layar berfrekuensi tetap, slot vsync pertama yang tidak mungkin dicapai pekerjaan di dalam anggaran (25,0 ms pada 60 Hz, 20,8 ms pada 120 Hz);
• rerata terpangkas — 2% frame terburuk dibuang — harus tetap di dalam 16,67 ms × 1,15.

Menghitung pelanggaran alih-alih merata-ratakannya membuat satu jeda pengumpulan sampah menjadi satu frame buruk, bukan satu jendela yang gagal; rerata terpangkas adalah pengaman agar pelanggaran yang jarang tetapi sangat besar tidak lolos hanya karena jumlahnya sedikit.

Kenapa ambangnya peduli pada layar Anda: monitor tetap 60 Hz bisa menampilkan frame setelah 16,7 ms atau 33,3 ms dan tidak ada di antaranya, sementara panel laptop dengan sinkronisasi adaptif mengembalikan frame 18 ms apa adanya sebagai 18 ms. Di bawah toleransi rerata dan P95 milik 2.1.0, perbedaan itu membiarkan panel adaptif lulus sambil melaju di 55 fps, sedangkan monitor 60 Hz harus menahan 60 yang sesungguhnya — GPU yang sama mendapat skor lebih rendah di meja daripada di dalam laptop. Maka sebelum adegan pertama, pengukuran irama sekitar 600 ms mengamati bagaimana layar Anda mengembalikan frame, dan kriterianya menyesuaikan diri supaya “mampu menahan 60 fps” menjadi klaim yang sama di setiap kelas layar. Kalau pengukuran menemukan layar yang terkunci di bawah ~50 Hz — mode hemat daya, kabel 30 Hz — tes menolak berjalan, alih-alih menilai GPU lewat sedotan 30 Hz.

Anggaran 16,67 ms itu sendiri tidak pernah berubah mengikuti refresh rate. Layar 120 Hz mengirim frame dengan irama 8,3 ms ketika bebannya ringan, tetapi kelulusan hanya menuntut Anda tetap di dalam anggaran 60 per detik — perangkat keras berrefresh tinggi diukur dengan takaran yang setara, bukan dihukum karena menampilkan frame tambahannya.

Pencariannya

Setiap adegan melangkah melalui sebuah mesin status: preflight → baseline → warmup → ramp → bracket → confirm → anchor.

1. Baseline mengukur satu beban ringan yang diketahui — ini menjadi acuan termal.
2. Ramp mengalikan beban sekitar 1,5× tiap jendela yang lolos sampai satu jendela gagal.
3. Bracket melakukan pencarian biner antara beban lolos terakhir dan beban gagal pertama sampai rentangnya menyempit ke sekitar 6%.
4. Confirm menuntut tiga jendela lolos berturut-turut pada beban kandidat, dalam anggaran empat jendela. Satu jendela buruk di awal masih bisa dipulihkan; dua kegagalan beruntun, atau anggaran habis tanpa tiga berturut-turut, menolak tingkat itu dan kandidatnya turun satu langkah.
5. Anchor menjalankan ulang beban dasar. Kalau sekarang lebih lambat 15% dibanding di awal, perangkatnya berubah di bawah kaki kami — hampir selalu throttling termal — dan adegan itu ditandai drift, bukannya berpura-pura tidak terjadi apa-apa. Besar perlambatannya juga dicatat, bukan hanya fakta bahwa itu terjadi.

Beberapa frame setelah setiap perubahan beban dibuang sebelum statistik dilanjutkan: mengubah beban berarti mengalokasikan ulang buffer GPU dan target render, dan peramban menagihnya sebagai satu frame yang sangat panjang. Cegukan itu milik transisi, bukan milik beban kerja — 2.1.0 ikut menghitungnya, dan pada adegan yang mengubah ukuran target rendernya di setiap anak tangga, hal itu menghentikan pencarian jauh di bawah kemampuan sebenarnya perangkat keras.

Setiap fase punya batas waktu keras (30 detik per adegan, 200 detik per tes). Memindahkan tab ke latar belakang menjeda pengukuran dan membatalkan jendela yang sedang berjalan; mengubah ukuran jendela membangun ulang adegan dan memanaskannya kembali. Tidak ada jalur di dalam mesin status itu yang bisa menggantung.

Dari beban menjadi skor

Penilaian adalah fungsi murni atas hasil yang tercatat — Anda bisa menghitungnya ulang dengan tangan:

1. Beban stabil maksimum tiap adegan dibagi dengan beban acuan adegan itu (konstanta kalibrasi yang dibekukan per versi; kasarnya, desktop yang solid dari 2025 mendarat di dekat 1,0).
2. Rasio diberi batas bawah 0,05 dan dipotong pada langit-langit tangga milik adegan itu sendiri — beban terberat yang secara fisik bisa disusun adegan tersebut, ditaruh kira-kira 10× di atas perangkat keras tercepat yang pernah kami ukur — sehingga skor hanya bisa berhenti naik di tempat pengukurannya sendiri berakhir. (2.1.0 memotong setiap adegan pada 20× yang datar; sebuah M4 Max menekan dua adegan ke batas itu dan yang ketiga ke langit-langit pengukuran, dan itulah sebabnya perangkat kelas atas Apple yang tak berkerabat terus melaporkan total yang nyaris sama.)
3. Rasio yang sudah dipotong digabungkan dengan rata-rata geometrik berbobot — lima adegan Signature memikul sebagian besar bobot, pembanding Canvas 2D 10%. Geometrik, karena itu menghargai keseimbangan: mesin yang bagus di semua hal mengalahkan mesin yang legendaris di satu hal dan payah di hal lain.
4. Kalikan 1000, terapkan pengurangan kestabilan — 3% per adegan bertanda, entah tandanya drift atau tingkat yang tak terkonfirmasi, maksimum 10% seluruhnya — lalu bulatkan.

Tingkatan adalah ambang tetap per versi, dan karena skor adalah 1000× mesin acuan, masing-masing sebenarnya kelipatan darinya: Dasar di bawah 1000, Seimbang sampai 2999, Cepat sampai 8999, Ekstrem di atasnya — yaitu di bawah 1×, sampai 3×, sampai 9×, lalu lebih jauh. Tingkatan ada supaya angka punya pegangan; subskor itulah informasi yang sebenarnya.

Apa yang membatalkan perbandingan

• Versi benchmark yang berbeda tidak pernah dibandingkan. Mengubah satu shader mengubah beban kerja; string versi di lembar hasil Anda adalah bagian dari skor.
• Tes kompatibilitas (tanpa WebGL2) hanya memakai adegan Klasik dan dinilai di ruangnya sendiri, dengan label yang jelas.
• Tes yang mengalami throttling — semua adegan terukur dan terkonfirmasi, tetapi perangkatnya memanas lalu melambat — adalah pengukuran nyata atas performa berkelanjutan, jadi dinilai seperti biasa dan masuk papan skor tertinggi dengan tandanya tertera di baris. Sebagian besar tes ponsel mendarat di sini; itu fisika, bukan cacat.
• Tes terdegradasi — ada adegan yang tidak menghasilkan apa pun yang bisa dipakai, atau tingkat beban yang tak pernah bisa dikonfirmasi pencarian — adalah batas bawah, bukan puncak, jadi tetap di luar papan. Semuanya tetap disimpan, tetap dihitung dalam median agregat, dan lembar hasil menyebut adegan mana dan mengapa.
• Kedua tanda itu ikut bersama tes ke dalam kumpulan data anonim kami, sehingga angka apa pun yang kami terbitkan bisa memisahkan keduanya.

Sebaran antartes, dengan angka

Pada mesin yang tercolok listrik dan sedang menganggur, tes berturut-turut biasanya berjarak beberapa persen saja — syarat jendela beruntun pada fase konfirmasi itulah yang membelinya. Dengan baterai, dalam mode hemat daya, atau dengan sasis yang hangat, siapkan diri untuk sebaran lebih lebar dan kemungkinan besar tanda throttling; itu bukan benchmark yang sedang berubah-ubah, itu perangkat Anda yang memang sedang menawarkan lebih sedikit. Mendinginkan perangkat dan mencoloknya ke listrik sebelum tes adalah satu hal paling ampuh yang bisa Anda lakukan demi angka yang mewakili. Apa yang bisa dan tidak bisa diukur benchmark peramban membahas apa yang harus dilakukan dengan angka itu setelah Anda mendapatkannya.