Class BufferQueue menghubungkan komponen yang menghasilkan buffering data grafis (produser) ke komponen yang menerima data untuk ditampilkan atau diproses lebih lanjut (konsumen). Hampir semua hal yang memindahkan buffering data grafis melalui sistem bergantung pada BufferQueue.
Allocator memori Gralloc melakukan alokasi buffering dan
diimplementasikan melalui dua antarmuka HIDL khusus vendor (lihat
hardware/interfaces/graphics/allocator/ dan
hardware/interfaces/graphics/mapper/). Fungsi
allocate() menggunakan argumen yang diharapkan (lebar, tinggi, format
piksel) serta kumpulan tanda penggunaan.
Produsen dan konsumen BufferQueue
Konsumen membuat dan memiliki struktur data BufferQueue dan dapat berada dalam
proses yang berbeda dengan produsennya. Saat produsen memerlukan buffer, produsen
akan meminta buffer gratis dari BufferQueue dengan memanggil
dequeueBuffer(), yang menentukan lebar, tinggi,
format piksel, dan flag penggunaan buffer. Kemudian, produsen akan mengisi buffer dan
menampilkan buffer ke antrean dengan memanggil queueBuffer(). Selanjutnya, konsumen memperoleh buffering dengan acquireBuffer() dan menggunakan konten buffering. Setelah selesai, konsumen akan menampilkan buffering ke
antrean dengan memanggil releaseBuffer(). Framework sinkronisasi mengontrol
cara buffer bergerak melalui pipeline grafis Android.
Beberapa karakteristik BufferQueue, seperti jumlah maksimum buffer yang dapat dimuat, ditentukan bersama oleh produsen dan konsumen. Namun, BufferQueue mengalokasikan buffer sesuai kebutuhan. Buffer dipertahankan kecuali jika karakteristiknya berubah; misalnya, jika produser meminta buffer dengan ukuran yang berbeda, buffer lama akan dibebaskan dan buffer baru dialokasikan sesuai permintaan.
Konten buffering tidak pernah disalin oleh BufferQueue, karena memindahkan begitu banyak data tidak efisien. Sebagai gantinya, buffering selalu diteruskan oleh handle.
Melacak BufferQueue dengan Systrace
Untuk memahami cara buffer grafis berpindah, gunakan Systrace, alat yang merekam aktivitas perangkat dalam waktu singkat. Kode grafis tingkat sistem dilengkapi dengan instrumen yang baik, seperti sebagian besar kode framework aplikasi yang relevan.
Untuk menggunakan Systrace, aktifkan tag gfx, view, dan
sched. Objek BufferQueue ditampilkan dalam rekaman aktivitas.
Misalnya, jika Anda mengambil rekaman aktivitas saat
video Play
Grafika (SurfaceView) sedang berjalan, baris berlabel SurfaceView akan memberi tahu Anda
jumlah buffering yang diantrekan pada waktu tertentu.
Nilai bertambah saat aplikasi aktif, yang memicu rendering frame oleh dekoder MediaCodec. Nilai berkurang saat SurfaceFlinger bekerja dan menggunakan buffer. Saat menampilkan video pada 30 fps, nilai antrean bervariasi dari 0 hingga 1 karena tampilan ~60 fps dapat mengimbangi sumber. SurfaceFlinger hanya aktif saat ada pekerjaan yang harus dilakukan, bukan 60 kali per detik. Sistem mencoba menghindari pekerjaan dan menonaktifkan VSYNC jika tidak ada yang memperbarui layar.
Jika beralih ke video Play Grafika (TextureView) dan mengambil rekaman aktivitas baru,
Anda akan melihat baris berlabel
com.android.grafika / com.android.grafika.PlayMovieActivity.
Ini adalah lapisan UI utama, yang merupakan BufferQueue lain. Karena TextureView
dirender ke dalam lapisan UI, bukan lapisan terpisah, semua
update yang didorong video ditampilkan di sini.
Gralloc
HAL alokator Gralloc
hardware/libhardware/include/hardware/gralloc.h
melakukan alokasi buffering melalui flag penggunaan. Flag penggunaan mencakup atribut
seperti:
- Seberapa sering memori akan diakses dari software (CPU)
- Seberapa sering memori akan diakses dari hardware (GPU)
- Apakah memori akan digunakan sebagai tekstur OpenGL ES (GLES)
- Apakah memori akan digunakan oleh encoder video
Misalnya, jika format buffering produsen menentukan piksel RGBA_8888, dan
produsen menunjukkan bahwa buffering akan diakses dari software (artinya aplikasi
akan menyentuh piksel di CPU), Gralloc akan membuat buffering dengan 4 byte per piksel
dalam urutan R-G-B-A. Jika produsen menentukan bahwa buffering-nya hanya akan
diakses dari hardware dan sebagai tekstur GLES, Gralloc dapat melakukan apa pun yang diinginkan driver
GLES, seperti pengurutan BGRA, tata letak swizzle non-linear, dan format warna
alternatif. Mengizinkan hardware menggunakan format pilihannya dapat
meningkatkan performa.
Beberapa nilai tidak dapat digabungkan di platform tertentu. Misalnya, flag encoder
video mungkin memerlukan piksel YUV, sehingga menambahkan akses software dan menentukan
RGBA_8888 akan gagal.
Nama sebutan channel yang ditampilkan oleh Gralloc dapat diteruskan di antara proses melalui Binder.
Buffer yang dilindungi
Flag penggunaan Gralloc GRALLOC_USAGE_PROTECTED memungkinkan
buffer grafis ditampilkan hanya melalui jalur yang dilindungi hardware. Bidang
overlay ini adalah satu-satunya cara untuk menampilkan konten DRM (buffer yang dilindungi DRM
tidak dapat diakses oleh SurfaceFlinger atau driver OpenGL ES).
Video yang dilindungi DRM hanya dapat ditampilkan di bidang overlay. Pemutar video yang mendukung konten yang dilindungi harus diterapkan dengan SurfaceView. Software yang berjalan di hardware yang tidak dilindungi tidak dapat membaca atau menulis buffering; jalur yang dilindungi hardware harus muncul di overlay Hardware Composer (yaitu, video yang dilindungi akan hilang dari layar jika Hardware Composer beralih ke komposisi OpenGL ES).
Untuk mengetahui detail tentang konten yang dilindungi, lihat DRM.