Panduan pemrograman swapchain komposisi

KOMPOSISI Swapchain API adalah penerus spiritual untuk swapchain DXGI, yang memungkinkan aplikasi untuk merender dan menyajikan konten ke layar. Ada beberapa manfaat untuk menggunakan API ini melalui swapchain DXGI. Kontrol yang lebih terperinci diberikan kepada aplikasi Anda mengenai status swapchain, dan lebih banyak kebebasan disediakan ketika datang ke bagaimana swapchain digunakan. Selain itu, API memberikan cerita yang lebih baik untuk waktu saat ini yang tepat.

Apa itu presentasi?

Presentasi adalah konsep menampilkan hasil operasi menggambar di layar. Hadiah adalah satu instans presentasi—permintaan untuk memperlihatkan hasil operasi menggambar ke satu buffer, di layar. Hadiah dapat berisi atribut tambahan yang menjelaskan cara menampilkan di layar. Dalam API ini, saat ini juga dapat memiliki waktu target, yang merupakan tanda waktu relatif sistem (waktu interupsi) yang menjelaskan waktu ideal bahwa saat ini harus ditampilkan. Aplikasi Anda dapat menggunakan ini untuk mengontrol laju konten yang muncul di layar secara lebih akurat, dan untuk menyinkronkan presentasi dengan peristiwa lain dalam sistem, seperti trek audio.

Inti presentasi adalah sinkronisasi. Artinya, operasi menggambar umumnya dilakukan oleh GPU, dibandingkan dengan CPU dan, dengan demikian, operasi tersebut dijalankan pada garis waktu asinkron dari CPU yang mengeluarkan operasi pada awalnya. Presentasi adalah operasi yang dikirimkan ke GPU yang memastikan bahwa operasi gambar yang dikeluarkan sebelumnya akan selesai sebelum buffer ditampilkan di layar.

Aplikasi Anda umumnya akan mengeluarkan banyak presentasi dari waktu ke waktu, dan memiliki beberapa tekstur untuk dipilih saat mengeluarkan hadiah. Aplikasi Anda harus menggunakan mekanisme sinkronisasi yang disediakan API ini untuk memastikan bahwa setelah Anda menarik dan menyajikan buffer, Anda tidak menarik buffer tersebut lagi sampai ada ditampilkan dan kemudian diganti dengan buffer baru dari hadiah berikutnya. Jika tidak, konten buffer yang dimaksudkan aplikasi Anda untuk disajikan pada awalnya dapat ditimpa seperti yang ada di layar.

Mode presentasi—komposisi, overlay multiplane, dan iflip

Buffer yang disajikan oleh aplikasi Anda dapat ditampilkan oleh sistem dengan beberapa cara yang berbeda.

Cara paling sederhana, yang merupakan default, adalah bahwa saat ini akan dikirim ke DWM, dan DWM akan merender bingkai berdasarkan buffer yang disajikan. Artinya, ada salinan (atau lebih akurat, render 3D) dari buffer presentasi ke backbuffer yang dikirim DWM ke layar. Metode menampilkan hadiah ini disebut Komposisi.

Mode yang lebih berkinerja menampilkan hadiah adalah memindai buffer presentasi langsung ke perangkat keras, dan menghilangkan salinan yang terjadi. Metode menampilkan hadiah ini disebut pemindaian langsung. Saat menangani presentasi, DWM dapat memutuskan untuk memprogram perangkat keras untuk langsung memindai buffer presentasi, dengan menetapkan buffer ke bidang overlay multiplane (atau bidang MPO, singkatnya), atau langsung membalik buffer ke perangkat keras (dikenal sebagai flip langsung).

Cara yang lebih berkinerja lebih baik untuk menampilkan hadiah adalah dengan menampilkan langsung oleh kernel grafis, dan melewati DWM sepenuhnya. Metode presentasi ini dikenal sebagai flip independen (iflip). Baik overlay multiplane maupun iflip dijelaskan dalam Untuk performa terbaik, gunakan model flip DXGI.

Komposisi adalah yang paling mudah didukung, tetapi juga yang paling tidak efisien. Permukaan perlu dialokasikan secara khusus agar memenuhi syarat untuk pemindaian langsung atau iflip, dan jenis alokasi khusus ini memiliki persyaratan sistem yang lebih ketat daripada swapchain komposisi. Ini hanya tersedia di WDDM 3.0 dan perangkat keras yang lebih besar. Akibatnya, aplikasi Anda dapat mengkueri dukungan API untuk presentasi khusus Komposisi, serta presentasi yang memenuhi syarat untuk pemindaian langsung atau iflip.

Pabrik presentasi, kemampuan pemeriksaan, dan manajer presentasi

Objek pertama yang akan digunakan aplikasi Anda dari API swapchain komposisi adalah pabrik presentasi. Pabrik presentasi dibuat oleh aplikasi Anda, dan terikat ke perangkat Direct3D yang diteruskan aplikasi Anda ke panggilan untuk membuat, dan dengan demikian, memiliki afinitas ke adaptor video yang terkait dengan perangkat tersebut.

Pabrik presentasi mengekspos metode untuk memeriksa apakah sistem saat ini dan perangkat grafis mampu menggunakan API swapchain komposisi atau tidak. Anda dapat menggunakan metode kemampuan seperti IPresentationFactory::IsPresentationSupported untuk memeriksa dukungan sistem. Jika metode kemampuan menunjukkan dukungan sistem untuk API, maka Anda dapat menggunakan pabrik presentasi untuk membuat manajer presentasi. Manajer presentasi ini adalah objek yang Anda gunakan untuk melakukan fungsi presentasi, dan terikat ke perangkat Direct3D dan adaptor video yang sama dengan pabrik presentasi yang digunakan untuk membuatnya.

Saat ini, persyaratan sistem untuk menggunakan API swapchain komposisi sama sekali adalah driver GPU yang mendukung WDDM (Windows Device Driver Model) 2.0, dan Windows 11 (Build 10.0.22000.194) atau lebih besar. Untuk menggunakan API swapchain komposisi dengan cara yang paling berkinerja (pemindaian langsung dan flip independen, atau iflip), sistem akan membutuhkan driver GPU yang mendukung WDDM 3.0.

Jika sistem tidak mampu menggunakan API swapchain komposisi, maka aplikasi Anda harus memiliki codepath terpisah untuk menangani presentasi menggunakan metode yang lebih lama, seperti swapchain DXGI.

Mendaftarkan buffer presentasi untuk disajikan

Manajer presentasi melacak buffer yang dapat disajikannya. Untuk menyajikan tekstur Direct3D, aplikasi Anda harus terlebih dahulu membuat tekstur tersebut dengan Direct3D, lalu mendaftarkannya dengan manajer presentasi. Ketika tekstur telah didaftarkan dengan manajer presentasi, tekstur tersebut disebut buffer presentasi, dan dapat dari titik tersebut dan seterusnya disajikan ke layar oleh manajer presentasi tersebut. Aplikasi Anda dapat menambahkan dan menghapus buffer presentasi sesuai keinginan, meskipun ada jumlah maksimum buffer presentasi yang dapat ditambahkan ke satu manajer presentasi (saat ini 31). Buffer presentasi ini juga dapat memiliki berbagai ukuran dan format yang akan berlaku saat buffer presentasi individu disajikan.

Tekstur dapat didaftarkan dengan sejumlah manajer presentasi; namun, itu tidak akan dianggap sebagai penggunaan normal dalam banyak kasus, dan akan memunculkan skenario sinkronisasi yang rumit bahwa aplikasi Anda akan bertanggung jawab untuk mengelola.

Menentukan konten yang akan disajikan

Secara umum, buffer yang kami sajikan perlu dikaitkan dengan konten di pohon visual. Oleh karena itu, kita perlu menentukan semacam pengikatan sehingga ketika masalah aplikasi Anda muncul, jelas di mana di pohon visual buffer yang disajikan dimaksudkan untuk pergi. Kami menyebut konten presentasi pengikatan ini.

Konten yang disajikan dapat mengambil banyak formulir. Aplikasi Anda mungkin ingin menyajikan satu buffer untuk ditampilkan, atau mungkin ingin menyajikan konten stereo dengan buffer untuk mata kiri dan kanan, dan sebagainya. Versi awal API ini menyediakan dukungan untuk menyajikan satu buffer ke layar.

Kami mendefinisikan permukaan presentasi menjadi bentuk konten presentasi di mana satu buffer disajikan pada satu waktu. Permukaan presentasi dapat diatur sebagai konten di pohon visual, dan dapat memperlihatkan buffer presentasi tunggal pada layar sekaligus. Presentasi Manajer Presentasi akan memperbarui buffer yang ditampilkan oleh satu atau beberapa permukaan presentasi secara atomik.

Manajer presentasi dapat digunakan untuk membuat satu atau beberapa permukaan presentasi untuk handel permukaan komposisi tertentu. Setiap handel permukaan komposisi dapat terikat ke satu atau beberapa visual di pohon visual (dengan strategi yang diuraikan dalam dokumentasi Windows.UI.Composition dan DirectComposition API) untuk menentukan hubungan antara permukaan presentasi terkait dan di mana ia muncul di pohon visualnya. Aplikasi Anda dapat memperbarui satu atau beberapa permukaan presentasi, yang dikirimkan ke sistem dan berlangsung pada operasi saat ini berikutnya.

Perhatikan bahwa manajer presentasi dapat menyajikan buffer presentasi apa pun ke sejumlah permukaan presentasi apa pun yang diinginkannya. Tidak ada batasan. Namun, terserah aplikasi Anda untuk melacak buffer mana yang telah Anda terbitkan, dan di mana, untuk memastikan bahwa Anda tidak mencoba mengeluarkan gambar baru ke buffer tersebut saat masih ditampilkan oleh permukaan presentasi.

Menerapkan properti ke permukaan presentasi

Selain menentukan buffer mana yang akan ditampilkan di permukaan presentasi, presentasi juga dapat menentukan berbagai properti lain ke permukaan presentasi tersebut. Ini termasuk properti yang menentukan bagaimana tekstur sumber akan diambil sampelnya, termasuk mode alfa dan ruang warna, bagaimana tekstur sumber akan diubah dan ditata, dan pembatasan yang ditampilkan atau dibaca kembali untuk konten yang dilindungi. Semua ini diekspos sebagai metode setter properti pada permukaan presentasi yang dapat diubah oleh aplikasi Anda dan, sama seperti pembaruan buffer, akan berlaku ketika aplikasi Anda ada.

Menyajikan ke permukaan penyajian

Setelah aplikasi Anda membuat permukaan presentasi, mendaftarkan buffer presentasi, dan menentukan pembaruan untuk masalah selama presentasi, Anda dapat menerapkan properti tersebut dengan menyajikan. Aplikasi Anda mengeluarkan hadiah melalui manajer presentasi. Ketika hadir diproses oleh sistem, semua pembaruan diterapkan secara atomik. Selain itu, aplikasi Anda juga dapat menentukan properti lain saat ini, seperti waktu ideal yang harus dilakukan ( waktu target saat ini) dan properti langka lainnya, seperti tingkat konten yang dimaksudkan, yang dapat digunakan untuk mengaktifkan mode refresh kustom pada sistem. Karena presentasi dapat dijadwalkan pada waktu tertentu, aplikasi Anda dapat mengeluarkan beberapa presentasi sebelumnya. Hadiah ini akan diproses satu per satu saat waktu terjadwal mereka tercapai.

Menyinkronkan presentasi

Aplikasi Anda harus yakin bahwa saat dirender ke buffer, dan masalah yang ada, aplikasi ini memilih buffer untuk dirender yang saat ini tidak direferensikan oleh hadiah sebelumnya yang beredar lainnya, karena hal ini dapat menimpa konten buffer yang menyajikan yang dimaksudkan. Selanjutnya, jika masalah aplikasi Anda merender ke buffer yang saat ini ditampilkan oleh permukaan presentasi di perangkat keras pemindaian, maka penyajiannya mungkin terhenti tanpa batas waktu, karena Direct3D melarang penyajian buffer depan.

API swapchain komposisi menyediakan beberapa mekanisme berbeda untuk memungkinkan aplikasi Anda mempraktikkan sinkronisasi buffer yang tepat yang telah disajikannya.

Buffer dikatakan tersedia jika tidak ada hadiah luar biasa yang mereferensikannya, dan saat ini tidak ditampilkan oleh sistem. Jika tidak, itu tidak tersedia. API menyediakan peristiwa untuk setiap buffer presentasi yang menunjukkan apakah buffer tersedia atau tidak. Ini adalah metode sinkronisasi paling sederhana untuk digunakan aplikasi Anda. Sebelum menggambar ke buffer dan menyajikannya, aplikasi Anda dapat memastikan bahwa peristiwa yang tersedia telah disinyalir. Peristiwa yang tersedia untuk buffer tertentu menjadi tidak bertanda saat telah terikat ke permukaan presentasi di API, dan tetap tidak bertanda sampai saat ini menjadi dihentikan.

Kedua, manajer presentasi melacak satu pagar pensiun yang ada untuk berkomunikasi dengan aplikasi Anda yang menyajikan telah selesai. Nilai pagar sesuai dengan pengidentifikasi saat ini dari saat ini yang memulai fase penghentian siklus hidupnya, seperti yang dibahas di bagian siklus hidup di bawah ini. Setelah hadiah memasuki fase ini, aman untuk mengasumsikan bahwa setiap buffer yang telah digantikan oleh hadiah berikutnya dapat digunakan kembali.

Metode sinkronisasi ini lebih canggih, tetapi memungkinkan kontrol yang lebih besar atas pembatasan alur kerja, dan lebih informatif tentang status sistem sehubungan dengan kedalaman antrean saat ini. Untuk gambaran umum siklus hidup saat ini, lihat bagian di bawah ini.

Siklus Hidup Hadiah

Presentasi manajer presentasi diantrekan ke sistem sebagai bagian dari antrean saat ini. Proses sistem disajikan dalam urutan antrean. Selain itu, setiap presentasi memiliki pengidentifikasi saji yang unik (ke manajer presentasi) yang terkait, yang merupakan nilai bertahap yang ditetapkan untuk saat ini, mulai dari 1 untuk presentasi pertama, dan bertambah 1 untuk setiap hadiah berikutnya. Pengidentifikasi saat ini digunakan di berbagai bagian API, seperti primitif sinkronisasi dan statistik presentasi, untuk merujuk pada hadiah tertentu.

Masing-masing saat ini bahwa masalah aplikasi Anda mengikuti siklus hidup tertentu, seperti yang dijelaskan di sini.

Setelah aplikasi Anda menyiapkan perubahan yang akan dibuat sebagai bagian dari hadiah, aplikasi akan menggunakan manajer presentasi untuk benar-benar mengeluarkan saat ini. Pada titik ini, saat ini dikatakan tertunda.

Setelah tertunda, hadiah akan duduk di antrean manajer presentasi saat ini, di mana ia akan tinggal sampai salah satu dari dua hal terjadi.

  • Hadiah menjadi dibatalkan. Manajer presentasi memungkinkan aplikasi Anda membatalkan presentasi yang dikeluarkan sebelumnya. Jika ini terjadi, maka saat ini dikatakan dibatalkan, dan kemudian segera dihentikan. Pada transisi ini, peristiwa buffer terkait yang tersedia untuk hadiah yang dibatalkan akan diperbarui, namun pagar yang dihentikan saat ini tidak akan memberi sinyal, karena yang ditampilkan sebelumnya (sebelum hadiah yang dibatalkan) akan tetap ditampilkan. Untuk alasan ini, aplikasi Anda tidak dapat menggunakan pagar pensiun saat ini untuk menentukan hadiah mana yang dibatalkan. Anda harus mempelajari ini dari statistik status saat ini yang kembali untuk setiap hadiah yang dibatalkan. Kami menyarankan agar aplikasi Anda menggunakan peristiwa buffer yang tersedia untuk menemukan buffer yang tersedia untuk disajikan setelah pembatalan. Setelah hadir ditampilkan, hadiah sebelumnya akan memulai proses penghentian, dan memperbarui pagar pensiun saat ini.
  • Jika tidak dibatalkan, saat ini akhirnya menjadi siap untuk diproses. Agar siap, dua kondisi utama harus dipenuhi.
    • Semua pekerjaan gambar yang dikeluarkan untuk konteks Direct3D sebelum saat ini dipanggil harus diselesaikan. Ini memastikan bahwa buffer tidak ditampilkan sebelum gambar aplikasi Anda selesai.
    • Jika waktu target saat ini ditentukan, maka waktu relatif sistem saat ini yang kami harapkan dapat menampilkan saat ini memenuhi waktu target yang diminta yang diterapkan aplikasi Anda saat ini.

Ketika sistem memutuskan untuk menemukan hadiah untuk ditampilkan di layar, sistem akan memilih hadiah terakhir yang telah menjadi siap untuk disajikan untuk ditampilkan. Jika ada beberapa hadiah siap, semua kecuali yang terbaru (yaitu, saat ini dengan pengidentifikasi saat ini terbesar) akan dilewati, dan segera memasuki status pensiun, di mana peristiwa buffer yang tersedia akan disinyalir, tetapi pagar pensiun saat ini tidak akan diberi sinyal, karena saat ini yang dilewati tidak beralih dari status yang ditampilkan.

Ketika hadiah siap dipilih untuk ditampilkan, sistem mulai melakukan pekerjaan untuk menampilkannya di layar. Ini mungkin berarti merender buffer sebagai bagian dari bingkai DWM, dan kemudian meminta perangkat keras menunjukkan bingkai tersebut di layar, atau mungkin berarti mengirim buffer langsung ke perangkat keras pemindaian dalam kasus iflip. Setelah ini berlangsung, saat ini dikatakan antrean. Pada tingkat tinggi, ini berarti sedang dalam perjalanan untuk ditampilkan.

Ketika perangkat keras berkeliling untuk menampilkan saat ini, yang ada dikatakan akan ditampilkan. Di sana akan tetap, terlihat di layar, sampai ada berikutnya masuk dan menggantinya.

Ketika hadiah berikutnya menjadi antrean, maka kita tahu bahwa perangkat keras pada akhirnya akan berhenti menunjukkan saat ini. Pada titik ini, saat ini dikatakan pensiun.

Ketika hadir berikutnya ditampilkan, maka saat ini dikatakan akan dihentikan.

Manajer presentasi mengekspos pagar pensiun saat ini, yang disinyalir ke pengidentifikasi saat ini dari setiap hadiah ketika memasuki status pensiun . Sinyal ini menunjukkan kepada aplikasi Anda bahwa telah menjadi aman untuk mengeluarkan pekerjaan penyajian ke buffer yang terkait dengan yang ada tanpa merusak hadiah sebelumnya. Jika masalah aplikasi Anda saat penyajian berfungsi selama status pensiun saat ini, maka pekerjaan penyajian akan diantrekan hingga saat ini memasuki status dihentikan, pada saat itu akan dijalankan. Jika pekerjaan penyajian dikeluarkan setelah saat ini dihentikan, maka akan segera dijalankan.

Berikut ini adalah diagram perubahan status ini.

Lifecycle of a present

Diagram buffer, permukaan, dan hadiah

Berikut ini adalah diagram yang berkaitan dengan manajer presentasi, buffer presentasi, permukaan presentasi, presentasi, dan pembaruan.

Diagram of buffers, surfaces, and presents

Diagram ini menunjukkan manajer presentasi, dengan dua permukaan presentasi dan tiga buffer presentasi, yang telah mengeluarkan dua presentasi yang dikeluarkan sejauh ini—penyangga pertama yang ditampilkan 1 di permukaan 1, dan buffer 2 di permukaan 2. Permukaan kedua yang diperbarui 2 untuk memperlihatkan buffer presentasi 3, dan tidak mengubah pengikatan permukaan 1. Setelah saat ini 2 ditampilkan, permukaan 1 akan menampilkan buffer 1, dan permukaan 2 akan menampilkan buffer 3, yang dapat dilihat dalam keadaan objek saat ini di manajer presentasi. Setiap yang ada dalam antrean akan berlaku ketika diproses dalam sistem.

Catatan

Karena Sekarang 2 tidak mengubah buffer untuk permukaan 1, permukaan 1 dibiarkan terikat ke buffer 1 dari sebelumnya saat ini. Dalam pengertian ini, ada referensi "implisit" pada buffer 1 saat ini 2, karena permukaan 1 akan tetap terikat ke buffer 1 setelah saat ini 2 ditampilkan.

Menambahkan permukaan presentasi ke pohon visual

Permukaan Presentasi adalah konten yang ada sebagai bagian dari pohon visual komposisi. Setiap permukaan presentasi terikat ke handel permukaan komposisi. Dalam Windows.UI.Composition, kuas permukaan dapat dibuat untuk handel permukaan komposisi yang sudah ada sebelumnya, dan terikat ke visual sprite. Dalam DirectComposition, permukaan komposisi dapat dibuat dari handel permukaan komposisi yang sudah ada sebelumnya dan terikat sebagai konten ke visual. Lihat dokumentasi masing-masing untuk setiap API untuk informasi selengkapnya.

API seperti Windows Media Foundation, dibangun untuk menggunakan API ini, mengekspos gagang permukaan komposisi yang akan terikat sebelumnya ke permukaan presentasi. Aplikasi juga dapat membuat handel permukaan komposisinya sendiri untuk kemudian mengikat ke permukaan presentasi dan menambahkan ke pohon visual dengan memanggil DCompositionCreateSurfaceHandle.

Membaca statistik presentasi

API swapchain komposisi mengekspos statistik presentasi, yang menjelaskan berbagai informasi tentang bagaimana hadiah tertentu diproses. Informasi umumnya mungkin menjelaskan bagaimana permukaan presentasi digunakan dalam bingkai DWM, titik waktu di mana ia muncul, apakah itu ditampilkan sama sekali, dan sebagainya.

Ada berbagai jenis statistik presentasi, dan dirancang untuk dapat diperluas dalam versi API yang akan datang. Aplikasi menggunakan manajer presentasi untuk mendaftar untuk menerima jenis statistik yang diminatinya. Statistik tersebut kemudian didorong ke antrean statistik manajer presentasi. Manajer presentasi mengekspos statistik peristiwa yang tersedia untuk aplikasi, yang merupakan handel peristiwa yang menunjukkan kapan antrean statistik memiliki item statistik yang tersedia untuk dibaca. Ketika itu terjadi, aplikasi Anda dapat menghapus antrean item statistik pertama dari antrean, membacanya, dan memprosesnya. Manajer presentasi akan mengatur ulang statistik yang tersedia saat aplikasi Anda telah membaca semua statistik yang saat ini dalam antrean. Aplikasi biasanya akan membaca dan memproses statistik dalam perulangan hingga statistik yang tersedia peristiwa telah diatur ulang. Akan umum bagi aplikasi Anda untuk memproses antrean statistik ini dalam perulangan kerja yang sama dengan yang Anda gunakan untuk mengeluarkan presentasi. Pola penggunaan yang disarankan adalah memprioritaskan statistik pemrosesan daripada mengeluarkan hadiah baru, untuk memastikan bahwa antrean tidak meluap.

Antrean memiliki jumlah statistik maksimum yang akan dilacaknya, yang akan berada pada urutan statistik 512-1024. Kedalaman antrean maksimum harus cukup untuk menyimpan ~5 detik statistik dalam kasus normal. Jika antrean statistik menjadi penuh, dan lebih banyak statistik dilaporkan, kebijakannya adalah statistik tertua akan dihentikan untuk memberi ruang.