Kecepatan penyegaran ganda

Android 11 menambahkan dukungan untuk perangkat dengan kecepatan refresh ganda. Ada tiga komponen utama pada fitur ini:

  • API HAL baru diperkenalkan di android.hardware.graphics.composer@2.4 .
  • Kode platform untuk mengurai konfigurasi perangkat untuk kecepatan refresh yang berbeda dan mengatur kecepatan refresh yang diinginkan
  • SDK dan NDK API baru yang memungkinkan aplikasi menyetel frekuensi gambar yang diinginkan

Penerapan

Dukungan khusus untuk peralihan kecepatan refresh telah ditambahkan ke android.hardware.graphics.composer@2.4 HAL . Kami sangat menyarankan penggunaan versi ini karena versi komposer HAL sebelumnya memiliki dukungan terbatas untuk peralihan kecepatan refresh.

Grup konfigurasi

Atribut baru CONFIG_GROUP telah ditambahkan ke IComposerClient::Attribute yang dapat dikueri menggunakan API getDisplayAttribute_2_4 . Atribut ini memungkinkan vendor mengelompokkan konfigurasi tampilan. Konfigurasi dalam grup yang sama memungkinkan peralihan yang mulus di antara keduanya di sebagian besar kasus. Grup konfigurasi digunakan oleh platform untuk membedakan konfigurasi mana yang dapat dialihkan di antara konfigurasi tersebut untuk mengalihkan kecepatan refresh dan bukan atribut lain untuk suatu konfigurasi.

Perhatikan contoh berikut yang menunjukkan manfaat menggunakan grup konfigurasi dengan perangkat yang mendukung empat konfigurasi tampilan:

  • 1080p@60Hz
  • 1080p@90Hz
  • 1080i@72Hz
  • 1080i@48Hz

Meskipun perangkat mendukung kecepatan refresh 48Hz, 60Hz, 72Hz, dan 90Hz, layar beroperasi pada mode berbeda dan peralihan dari 60Hz ke 72Hz akan mengubah konfigurasi tampilan dari 1080p ke 1080i, yang mungkin bukan perilaku yang diinginkan. Ini diselesaikan dengan menggunakan grup konfigurasi. Dengan mengelompokkan 60Hz dan 90Hz dalam satu grup konfigurasi dan 48Hz dan 72Hz di grup konfigurasi lain. Platform mengetahui bahwa ia dapat beralih antara 60Hz dan 90Hz dan antara 48Hz dan 72Hz tetapi tidak antara 60Hz dan 72Hz karena hal ini akan mengakibatkan perubahan konfigurasi, bukan sekadar mengubah kecepatan refresh.

Pembaruan API Komposer

dapatkanDisplayVsyncPeriod
Untuk kontrol dan prediktabilitas yang lebih baik saat mengubah kecepatan refresh, getDisplayVsyncPeriod telah ditambahkan. getDisplayVsyncPeriod mengembalikan kecepatan refresh saat ini (dalam hal periode vsync) tempat layar beroperasi. Hal ini sangat berguna ketika transisi antara kecepatan refresh dan kecepatan refresh saat ini diperlukan oleh platform untuk memutuskan kapan memulai frame berikutnya.
setActiveConfigWithConstraints
Metode setActiveConfigWithConstraints adalah ekstensi baru dari metode setActiveConfig yang sudah ada dan memberikan informasi lebih lanjut tentang perubahan konfigurasi. Batasan diberikan sebagai bagian dari parameter vsyncPeriodChangeConstraints dan berisi parameter berikut.
    waktu yang diinginkanNanos
    Waktu di CLOCK_MONOTONIC setelah periode vsync dapat berubah (yaitu periode vsync tidak boleh berubah sebelum waktu ini). Hal ini berguna ketika platform ingin merencanakan perubahan kecepatan refresh terlebih dahulu, namun sudah memiliki beberapa buffer dalam antrean untuk dipresentasikan. Platform menetapkan waktu ini sesuai dengan buffer tersebut dan memastikan bahwa transisi kecepatan refresh akan selancar mungkin.
    mulusDiperlukan
    Jika benar, perubahan periode vsync harus terjadi dengan lancar tanpa artefak visual yang terlihat. Tanda ini digunakan oleh platform ketika perubahan kecepatan refresh diperlukan sebagai akibat dari perubahan konten (misalnya, perangkat dalam keadaan idle dan animasi dimulai). Hal ini memberikan kesempatan kepada vendor untuk tidak mengizinkan perubahan konfigurasi tertentu jika perubahan tersebut dapat mengakibatkan artefak visual yang terlihat. Jika konfigurasi tidak dapat diubah dengan mulus dan seamlessRequired disetel ke true , implementasi diharapkan mengembalikan SEAMLESS_NOT_POSSIBLE sebagai kode pengembalian dan memanggil callback onSeamlessPossible yang baru ketika perubahan konfigurasi yang sama dapat dilakukan dengan lancar.

Setelah berhasil, implementasi mengembalikan VsyncPeriodChangeTimeline yang memberi tahu platform kapan perubahan kecepatan refresh akan terjadi. Parameter newVsyncAppliedTimeNanos perlu disetel ke waktu di CLOCK_MONOTONIC ketika tampilan baru akan mulai disegarkan pada periode vsync baru. Hal ini, bersama dengan desiredTimeNanos memungkinkan platform untuk merencanakan terlebih dahulu peralihan kecepatan refresh dan mulai mencentang aplikasi untuk kecepatan refresh baru terlebih dahulu. Hal ini memungkinkan transisi kecepatan refresh yang mulus.

Beberapa implementasi memerlukan frame penyegaran untuk dikirim sebelum kecepatan penyegaran dapat dikirim. Untuk itu, HAL memiliki parameter refreshRequired untuk menunjukkan bahwa bingkai penyegaran diperlukan dan refreshTimeNanos untuk menunjukkan vsync pertama tempat bingkai penyegaran perlu dikirim setelahnya.

onVsyncPeriodTimingChanged [panggilan balik]
Callback baru yang dapat dipanggil oleh HAL untuk menunjukkan kepada platform bahwa beberapa parameter timeline berubah dan platform perlu menyesuaikan timeline-nya. Callback ini diharapkan dipanggil jika karena alasan tertentu timeline lama terlewatkan karena waktu pemrosesan yang lama di HAL atau frame penyegaran yang terlambat.

Bagaimana platform memutuskan untuk mengubah kecepatan refresh?

Pemilihan kecepatan refresh terjadi di dua layanan sistem berikut:

Manajer Tampilan
DisplayManager menetapkan kebijakan tingkat tinggi seputar kecepatan refresh. Ini menetapkan konfigurasi tampilan default, yang sama dengan konfigurasi HAL komposer. Selain itu, ini menetapkan rentang nilai minimum dan maksimum untuk dipilih SurfaceFlinger sebagai kecepatan refresh.
PermukaanFlinger
Menentukan kecepatan refresh dengan mengatur konfigurasi yang berada dalam grup konfigurasi yang sama dengan konfigurasi default dan dengan kecepatan refresh dalam rentang min/maks.

Display Manager menjalankan langkah-langkah berikut untuk menentukan kebijakan:

  • Menemukan ID konfigurasi default dengan menanyakan konfigurasi aktif dari SurfaceFlinger
  • Membatasi rentang nilai minimum dan maksimum dengan melakukan iterasi pada kondisi sistem
    • Pengaturan kecepatan refresh default : Nilai kecepatan refresh default diatur dalam overlay konfigurasi R.integer.config_defaultRefreshRate . Nilai ini digunakan untuk menentukan kecepatan refresh perangkat standar untuk animasi dan interaksi sentuhan.
    • Pengaturan kecepatan refresh puncak : Nilai kecepatan refresh puncak dibaca dari Settings.System.PEAK_REFRESH_RATE . Nilai ini diubah saat runtime untuk mencerminkan pengaturan perangkat saat ini (misalnya dari opsi menu). Nilai default diatur dalam overlay konfigurasi R.integer.config_defaultPeakRefreshRate .
    • Pengaturan kecepatan refresh minimum : Nilai kecepatan refresh minimum dibaca dari Settings.System.MIN_REFRESH_RATE . Nilai ini dapat diubah saat runtime untuk mencerminkan pengaturan perangkat saat ini (misalnya dari opsi menu). Nilai defaultnya adalah 0, jadi tidak ada nilai minimum default.
    • Aplikasi meminta ModeId : Aplikasi dapat mengatur WindowManager.LayoutParams.preferredDisplayModeId untuk mencerminkan konfigurasi pilihan tempat layar harus dioperasikan. Di sebagian besar kondisi DisplayManager menetapkan ID konfigurasi default dan menetapkan kecepatan refresh minimum dan maksimum agar sesuai dengan kecepatan refresh konfigurasi.
    • Penghemat Baterai : Kecepatan refresh dibatasi hingga 60Hz atau lebih rendah saat perangkat dalam mode daya rendah, yang ditunjukkan melalui Settings.Global.LOW_POWER_MODE.

Setelah DisplayManager menetapkan kebijakan, SurfaceFlinger menetapkan kecepatan refresh berdasarkan lapisan aktif (lapisan yang mengantri pembaruan bingkai). Jika pemilik lapisan menetapkan kecepatan bingkai , SurfaceFlinger mencoba mengatur kecepatan refresh ke sesuatu yang merupakan pengganda dari kecepatan tersebut. Misalnya jika dua lapisan aktif mengatur kecepatan bingkainya menjadi 24 dan 60, SurfaceFlinger akan memilih 120Hz jika tersedia. Jika kecepatan refresh tersebut tidak tersedia untuk SurfaceFlinger, SurfaceFlinger akan mencoba memilih kecepatan refresh yang memiliki kesalahan minimal untuk kecepatan bingkai. Untuk informasi lebih lanjut, lihat dokumentasi pengembang di developer.android.com

SurfaceFlinger mempertahankan tanda berikut untuk mengontrol bagaimana kecepatan refresh ditentukan:

  • ro.surface_flinger.use_content_detection_for_refresh_rate: Jika disetel, kecepatan refresh ditentukan berdasarkan lapisan aktif, meskipun kecepatan bingkai tidak disetel. SurfaceFlinger mempertahankan heuristik di mana ia menemukan fps rata-rata yang diposting oleh lapisan buffer dengan melihat stempel waktu presentasi yang dilampirkan ke buffer.
  • ro.surface_flinger.set_touch_timer_ms : jika > 0, kecepatan refresh default akan digunakan saat pengguna menyentuh layar selama batas waktu yang dikonfigurasi. Heuristik ini dilakukan agar siap dengan kecepatan refresh default untuk animasi.
  • ro.surface_flinger.set_idle_timer_ms : jika > 0, kecepatan refresh minimum akan digunakan ketika tidak ada pembaruan layar untuk batas waktu yang dikonfigurasi.
  • ro.surface_flinger.set_display_power_timer_ms : jika > 0, kecepatan refresh default akan digunakan saat menyalakan layar (atau saat keluar dari AOD) untuk batas waktu yang dikonfigurasi.

API Kecepatan Bingkai

API kecepatan bingkai memungkinkan aplikasi memberi tahu platform Android tentang kecepatan bingkai yang diinginkan dan tersedia pada aplikasi yang menargetkan Android 11. Untuk mempelajari lebih lanjut tentang API kecepatan bingkai, lihat dokumentasi pengembang di developer.android.com .

Opsi pengembang

Opsi pengembang baru telah ditambahkan ke menu yang mengubah overlay pada tampilan dengan kecepatan refresh saat ini. Opsi baru ada di bawah Pengaturan > Sistem > Opsi pengembang > Tampilkan kecepatan refresh.