Mari kita lihat struktur data utama, yang merupakan {i>input<i} dan {i>output<i} ke pipeline rendering.
Struktur data ini adalah:
- Hierarki frame terdiri dari node lokal dan jarak jauh yang mewakili situs web dokumen berada di mana proses render dan perender Blink mana.
- Hierarki fragmen yang tidak dapat diubah mewakili output (dan input ke) algoritma pembatasan tata letak.
- Hierarki properti mewakili transformasi, klip, efek, dan hierarki scroll suatu dokumen web. Ini digunakan di seluruh pipeline.
- Daftar tampilan dan potongan cat adalah input untuk algoritma raster dan layerization.
- Frame Compositor mengenkapsulasi permukaan, permukaan render, dan tekstur GPU kartu yang digunakan untuk menggambar menggunakan GPU.
Sebelum berjalan melalui struktur-struktur data ini, contoh berikut dibuat berdasarkan satu dari peninjauan arsitektur. Ini digunakan di seluruh dokumen ini dengan demonstrasi bagaimana data tersebut struktur yang umum diterapkan.
<!-- Example code -->
<html>
<div style="overflow: hidden; width: 100px; height: 100px;">
<iframe style="filter: blur(3px);
transform: rotateZ(1deg);
width: 100px; height: 300px"
id="one" src="foo.com/etc"></iframe>
</div>
<iframe style="top:200px;
transform: scale(1.1) translateX(200px)"
id="two" src="bar.com"></iframe>
</html>
Pohon frame
Chrome terkadang dapat memilih untuk merender frame lintas origin dalam proses {i>render<i} yang berbeda dari {i>frame<i} induknya.
Dalam kode contoh, total ada tiga frame:
Dengan isolasi situs, Chromium menggunakan dua proses render untuk merender halaman web ini. Setiap proses render memiliki representasi sendiri dari hierarki frame untuk halaman web tersebut:
Frame yang dirender dalam proses berbeda direpresentasikan sebagai frame jarak jauh. {i>Frame<i} jarak jauh menyimpan informasi minimum yang diperlukan untuk bertindak sebagai {i>placeholder<i} dalam {i>rendering<i}, seperti dimensinya. Jika tidak, frame jarak jauh tidak berisi informasi apa pun yang diperlukan untuk merender kontennya yang sebenarnya.
Sebaliknya, {i>frame<i} lokal mewakili {i>frame<i} yang melewati oleh pipeline rendering. {i>Local frame<i} berisi semua informasi yang diperlukan untuk mengubah data untuk bingkai tersebut (seperti hierarki DOM dan data gaya) menjadi sesuatu yang dapat dirender dan ditampilkan.
Pipeline rendering beroperasi pada perincian
fragmen hierarki frame lokal.
Pertimbangkan contoh yang lebih rumit dengan foo.com sebagai frame utama:
<iframe src="bar.com"></iframe>
Dan subframe bar.com berikut:
<iframe src="foo.com/etc"></iframe>
Meskipun hanya ada dua perender, sekarang ada tiga frame lokal
fragmen hierarki, dengan dua dalam proses render untuk foo.com dan satu dalam
proses render untuk bar.com:
Untuk menghasilkan satu {i>frame<i} compositor untuk laman web, Viz secara bersamaan meminta {i>frame<i} compositor dari {i>root frame<i} masing-masing tiga pohon {i>frame<i} lokal, dan kemudian menggabungkannya. Lihat juga bagian frame compositor.
Frame utama foo.com dan subframe foo.com/other-page
merupakan bagian dari pohon {i>frame<i} yang sama dan
dirender dalam proses yang sama.
Namun, kedua {i>frame<i} tersebut masih memiliki
siklus proses dokumen
karena merupakan bagian dari fragmen hierarki frame lokal yang berbeda.
Karena alasan ini, tidak mungkin menghasilkan satu frame compositor untuk keduanya dalam satu update.
Proses {i>render<i} tidak memiliki informasi yang cukup
untuk menggabungkan frame compositor yang dihasilkan untuk foo.com/other-page
langsung ke frame compositor untuk frame utama foo.com.
Misalnya, frame induk bar.com di luar proses dapat memengaruhi tampilan iframe foo.com/other-url,
dengan mengubah iframe dengan CSS atau menutupi bagian iframe dengan elemen lain di DOM-nya.
Waterfall pembaruan properti visual
Properti visual seperti faktor skala perangkat dan ukuran area pandang memengaruhi output yang dirender dan harus disinkronkan antara fragmen hierarki frame lokal. Akar dari setiap fragmen hierarki frame lokal memiliki objek widget yang terkait dengannya. Pembaruan properti visual mengarah ke widget frame utama sebelum diterapkan ke widget lainnya dari atas ke bawah.
Misalnya, saat ukuran area pandang berubah:
Proses ini tidak seketika, sehingga properti visual replika juga menyertakan token sinkronisasi. Kompositor Viz menggunakan token sinkronisasi ini untuk menunggu semua fragmen hierarki frame lokal untuk mengirimkan {i>frame<i} compositor dengan token sinkronisasi saat ini. Proses ini menghindari pencampuran bingkai compositor dengan properti visual yang berbeda.
Hierarki fragmen yang tidak dapat diubah
Hierarki fragmen yang tidak dapat diubah adalah output dari tahap tata letak rendering {i>pipelines<i} yang sama. Elemen ini mewakili posisi dan ukuran semua elemen pada halaman (tanpa transformasi yang diterapkan).
Setiap fragmen mewakili bagian dari elemen DOM. Biasanya hanya ada satu fragmen per elemen, tetapi lebih banyak lagi jika dibagi menjadi halaman yang berbeda saat mencetak, atau kolom ketika menggunakan konteks multi-kolom.
Setelah tata letak, setiap fragmen menjadi tidak dapat diubah dan tidak pernah diubah lagi. Yang penting, kami juga menerapkan beberapa batasan tambahan. Kami tidak akan:
- Izinkan "naik" {i>reference <i}dalam hierarki. (Turunan tidak dapat memiliki pointer ke induknya.)
- "gelembung" secara menurun (anak hanya membaca informasi dari turunannya, bukan dari induknya).
Dengan batasan ini, kita dapat menggunakan kembali fragmen untuk tata letak berikutnya. Tanpa batasan ini, kami harus sering membuat ulang seluruh pohon, dan membutuhkan biaya yang mahal.
Sebagian besar tata letak biasanya berupa pembaruan bertahap, misalnya, aplikasi web yang memperbarui sebagian kecil UI sebagai respons terhadap klik pengguna pada elemen. Idealnya, tata letak seharusnya hanya berfungsi proporsional dengan apa yang sebenarnya berubah di layar. Kita dapat mencapai ini dengan menggunakan kembali sebanyak mungkin bagian dari pohon sebelumnya. Artinya (biasanya) kami hanya perlu membangun kembali tulang belakang pohon.
Di masa depan, desain yang tidak dapat diubah ini memungkinkan kita melakukan hal-hal menarik seperti meneruskan hierarki fragmen yang tidak dapat diubah melintasi batas thread jika diperlukan (untuk melakukan fase berikutnya pada thread yang berbeda), membuat beberapa pohon untuk animasi tata letak yang mulus, atau melakukan tata letak spekulatif paralel. Hal ini juga memberi kita potensi dari tata letak multi-threading itu sendiri.
Item fragmen sebaris
Konten inline (terutama teks yang diberi gaya) menggunakan representasi yang sedikit berbeda. Alih-alih struktur pohon dengan kotak dan petunjuk, kami merepresentasikan konten inline dalam daftar datar yang mewakili hierarki. Manfaat utamanya adalah representasi daftar rata untuk {i>inline<i} itu cepat, berguna untuk memeriksa atau mengkueri struktur data inline, dan hemat memori. Hal ini sangat penting untuk performa rendering web, karena rendering teks sangat kompleks, dan dapat dengan mudah menjadi bagian paling lambat dari pipeline kecuali sangat dioptimalkan.
Daftar datar dibuat untuk setiap konteks pemformatan inline dalam urutan penelusuran depth-first dari subhierarki tata letak inline-nya. Setiap entri dalam daftar adalah tuple (objek, jumlah turunan). Contohnya, perhatikan DOM ini:
<div style="width: 0;">
<span style="color: blue; position: relative;">Hi</span> <b>there</b>.
</div>
Properti width disetel ke 0 sehingga baris digabungkan antara "Hi" dan "di sana".
Ketika konteks pemformatan {i>inline<i} untuk situasi ini direpresentasikan sebagai pohon, Tampilannya akan terlihat seperti berikut:
{
"Line box": {
"Box <span>": {
"Text": "Hi"
}
},
"Line box": {
"Box <b>": {
"Text": "There"
}
},
{
"Text": "."
}
}
Daftar datar akan terlihat seperti ini:
- (Kotak garis, 2)
- (Kotak <span>, 1)
- (Teks "Halo", 0)
- (Kotak baris, 3)
- (Kotak <b>, 1)
- (Kirim teks ke "di sana", 0)
- (Teks ".", 0)
Ada banyak pengguna struktur data ini: API aksesibilitas,
dan geometry API seperti
getClientRects,
dan contenteditable.
Masing-masing memiliki persyaratan yang berbeda.
Komponen-komponen ini mengakses struktur data datar melalui kursor praktis.
Kursor
memiliki API, seperti MoveToNext, MoveToNextLine, CursorForChildren.
Representasi kursor ini sangat efektif untuk konten teks, karena beberapa alasan:
- Iterasi pada urutan penelusuran depth-first sangat cepat. Ini sangat sering digunakan karena mirip dengan gerakan {i>caret<i}. Karena ini adalah daftar datar, pencarian {i>depth-first<i} hanya menambah selisih {i>array<i}, yang menyediakan iterasi cepat dan lokalitas memori.
- Alat ini menyediakan penelusuran luas-pertama, yang diperlukan saat, misalnya, mengecat latar belakang garis dan kotak {i>inline<i}.
- Mengetahui jumlah turunan membuat perpindahan ke saudara berikutnya dengan cepat (cukup tambahkan offset array dengan angka tersebut).
Hierarki properti
DOM adalah hierarki elemen (ditambah simpul teks), dan CSS dapat menerapkan berbagai gaya ke elemen.
Hal ini muncul dalam empat cara:
- Tata letak: input ke algoritme batasan tata letak.
- Cat: cara melukis dan raster elemen (tetapi bukan turunannya).
- Visual: efek raster/gambar yang diterapkan ke subhierarki DOM, seperti transformasi, filter, dan kliping.
- Men-scroll: sudut rata sumbu dan membulat {i>clipping<i} dan {i>scrolling<i} pada subpohon yang ada di dalamnya.
Pohon properti adalah struktur data yang menjelaskan bagaimana efek visual dan scroll diterapkan pada elemen DOM. Studi kasus memberikan sarana untuk menjawab pertanyaan seperti: di mana, relatif terhadap layar, adalah elemen DOM tertentu, berdasarkan ukuran dan posisi tata letaknya? Dan: urutan operasi GPU apa yang harus digunakan untuk menerapkan efek visual dan scroll?
Efek visual dan scroll di web sangatlah rumit dalam kejayaannya. Hal terpenting yang dilakukan pohon properti adalah menerjemahkan kompleksitas itu menjadi satu struktur data yang secara tepat mewakili struktur dan maknanya, sementara pada saat yang sama menghilangkan kerumitan lainnya dari DOM dan CSS. Ini memungkinkan kita menerapkan algoritma untuk komposisi dan scroll dengan lebih percaya diri. Khususnya:
- Geometri yang berpotensi rentan kesalahan dan penghitungan lainnya dapat dipusatkan di satu tempat.
- Kompleksitas pembuatan dan pembaruan hierarki properti diisolasi ke dalam satu tahap pipeline rendering.
- Jauh lebih mudah dan lebih cepat untuk mengirim pohon properti ke berbagai thread dan proses yang berbeda daripada status DOM penuh, sehingga dapat digunakan di banyak kasus penggunaan.
- Semakin banyak kasus penggunaannya, semakin banyak keberhasilan yang bisa kita dapatkan dari {i>caching<i} geometri yang dibangun di atas, karena mereka dapat menggunakan kembali {i>password<i} satu sama lain di cache oleh pengguna.
RenderingNG menggunakan hierarki properti untuk berbagai tujuan, termasuk:
- Memisahkan komposisi dari cat, dan mengomposisikan dari utas utama.
- Menentukan strategi penyusunan / menggambar yang optimal.
- Pengukuran IntersectionObserver geometri.
- Menghindari pekerjaan untuk elemen di luar layar dan ubin tekstur GPU.
- Membatalkan validasi cat dan raster secara efisien dan akurat.
- Pengukuran geser tata letak dan largest contentful paint di Core Web Vitals.
Setiap dokumen web memiliki empat hierarki properti terpisah: transformasi, klip, efek, dan scroll.(*) Pohon transformasi merepresentasikan transformasi dan scroll CSS. (Transformasi scroll direpresentasikan sebagai matriks transformasi 2D.) Hierarki klip mewakili klip tambahan. Pohon efek mewakili semua efek visual lainnya: opasitas, filter, topeng, mode campuran, dan jenis klip lain seperti jalur klip. Pohon {i>scroll<i} mewakili informasi tentang {i>scrolling<i}, seperti bagaimana menggulir rantai bersama-sama; diperlukan untuk melakukan scroll pada thread compositor. Tiap node dalam hierarki properti mewakili scroll atau efek visual yang diterapkan oleh elemen DOM. Jika terjadi dengan banyak efek, mungkin ada lebih dari satu simpul pohon properti di setiap pohon untuk elemen yang sama.
Topologi setiap pohon seperti representasi DOM yang jarang. Misalnya, jika ada tiga elemen DOM dengan klip tambahan, maka akan ada tiga node pohon klip, dan struktur pohon klip akan mengikuti hubungan blok yang memuat antara klip tambahan. Terdapat tautan di antara pohon-pohon tersebut. Tautan ini menunjukkan hierarki DOM relatif, dan merupakan urutan penerapan dari node. Misalnya, jika transformasi pada elemen DOM berada di bawah elemen DOM lain dengan filter, tentu saja transformasi akan diterapkan sebelum filter.
Setiap elemen DOM memiliki status hierarki properti, yang merupakan 4-tuple (transformasi, klip, efek, gulir) yang menunjukkan klip ancestor terdekat, mengubah, dan mempengaruhi simpul pohon yang berlaku pada elemen itu. Ini sangat nyaman, karena dengan informasi ini kami tahu persis daftar klip, transformasi, dan efek yang berlaku untuk elemen itu, beserta urutannya. Ini memberi tahu kita letaknya di layar dan cara menggambarnya.
Contoh
(sumber)
<html>
<div style="overflow: scroll; width: 100px; height: 100px;">
<iframe style="filter: blur(3px);
transform: rotateZ(1deg);
width: 100px; height: 300px"
id="one" srcdoc="iframe one"></iframe>
</div>
<iframe style="top:200px;
transform: scale(1.1) translateX(200px)" id=two
srcdoc="iframe two"></iframe>
</html>
Untuk contoh sebelumnya (yang sedikit berbeda dari yang ada di pendahuluan), berikut adalah elemen utama hierarki properti yang dihasilkan:
Menampilkan daftar dan potongan cat
Item tampilan berisi perintah menggambar tingkat rendah (lihat di sini) yang dapat diraster dengan Skia. Item tampilan biasanya sederhana, hanya dengan beberapa perintah gambar, seperti menggambar batas atau latar belakang. Menggambar hierarki cat akan melakukan iterasi pada hierarki tata letak dan fragmen terkait sesuai dengan urutan penggambaran CSS untuk menghasilkan daftar item tampilan.
Contoh:
<div id="green" style="background:green; width:80px;">
Hello world
</div>
<div id="blue" style="width:100px;
height:100px; background:blue;
position:absolute;
top:0; left:0; z-index:-1;">
</div>
HTML dan CSS ini akan menghasilkan daftar tampilan berikut, dengan setiap sel merupakan item tampilan:
| Latar belakang tampilan | Latar belakang #blue |
Latar belakang #green |
Teks inline #green |
|---|---|---|---|
drawRect dengan ukuran 800x600 dan warna putih. |
drawRect dengan ukuran 100x100 pada posisi 0,0 dan warna biru. |
drawRect dengan ukuran 80x18 pada posisi 8,8 dan warna hijau. |
drawTextBlob dengan posisi 8,8 dan teks "Hello world". |
Daftar item tampilan diurutkan dari belakang ke depan. Pada contoh di atas, div hijau berada sebelum div biru dalam urutan DOM, tetapi urutan cat CSS mengharuskan bahwa div biru indeks-z negatif sebelum (langkah 3) div hijau (langkah 4.1). Item tampilan kurang lebih berkaitan dengan langkah-langkah kecil dari spesifikasi urutan gambar CSS. Satu elemen DOM bisa menghasilkan beberapa item tampilan, seperti bagaimana #green memiliki item tampilan untuk latar belakang dan item tampilan lainnya untuk teks inline. Perincian ini penting untuk menggambarkan kompleksitas penuh dari spesifikasi pesanan cat CSS, seperti interleaving yang dibuat dengan margin negatif:
<div id="green" style="background:green; width:80px;">
Hello world
</div>
<div id="gray" style="width:35px; height:20px;
background:gray;margin-top:-10px;"></div>
Tindakan ini menghasilkan daftar tampilan berikut, di mana setiap sel merupakan item tampilan:
| Latar belakang tampilan | Latar belakang #green |
Latar belakang #gray |
Teks inline #green |
|---|---|---|---|
drawRect dengan ukuran 800x600 dan warna putih. |
drawRect dengan ukuran 80x18 pada posisi 8,8 dan warna hijau. |
drawRect dengan ukuran 35x20 di posisi 8,16 dan warna abu-abu. |
drawTextBlob dengan posisi 8,8 dan teks "Hello world". |
Daftar item tampilan disimpan dan digunakan kembali oleh pembaruan berikutnya. Jika objek tata letak tidak berubah selama proses {i>cat tree<i}, item tampilannya disalin dari daftar sebelumnya. Pengoptimalan tambahan bergantung pada properti spesifikasi pesanan cat CSS: konteks tumpukan melukis secara atomik. Jika tidak ada objek tata letak yang berubah dalam konteks yang bertumpuk, jalan di pohon cat melewatkan konteks penumpukan dan menyalin seluruh urutan item tampilan dari daftar sebelumnya.
Status hierarki properti saat ini dipertahankan selama tahap paint tree dan daftar item tampilan dikelompokkan menjadi "bagian" item tampilan yang memiliki status hierarki properti yang sama. Hal ini ditunjukkan dalam contoh berikut:
<div id="scroll" style="background:pink; width:100px;
height:100px; overflow:scroll;
position:absolute; top:0; left:0;">
Hello world
<div id="orange" style="width:75px; height:200px;
background:orange; transform:rotateZ(25deg);">
I'm falling
</div>
</div>
Tindakan ini menghasilkan daftar tampilan berikut, di mana setiap sel merupakan item tampilan:
| Latar belakang tampilan | Latar belakang #scroll |
Teks inline #scroll |
Latar belakang #orange |
Teks inline #orange |
|---|---|---|---|---|
drawRect dengan ukuran 800x600 dan warna putih. |
drawRect dengan ukuran 100x100 di posisi 0,0 dan warna merah muda. |
drawTextBlob dengan posisi 0,0 dan teks "Hello world". |
drawRect dengan ukuran 75x200 di posisi 0,0 dan warna oranye. |
drawTextBlob dengan posisi 0,0 dan teks "Saya jatuh". |
Hierarki properti transformasi dan potongan cat akan (disederhanakan agar lebih singkat):
Daftar potongan cat yang berurutan, yang merupakan kelompok item tampilan dan status hierarki properti, yang merupakan input untuk langkah pelapisan dari pipeline rendering. Seluruh daftar potongan cat dapat digabungkan menjadi satu lapisan gabungan dan diraster bersama, tetapi hal ini akan membutuhkan proses rasterisasi yang mahal setiap kali pengguna men-scroll. Sebuah lapisan gabungan dapat dibuat untuk setiap bagian cat dan diraster satu per satu untuk menghindari semua raster ulang, tetapi itu akan cepat menghabiskan memori GPU. Langkah pelapisan harus melakukan kompromi antara memori GPU dan mengurangi biaya bila ada perubahan. Pendekatan umum yang baik adalah menggabungkan potongan secara {i>default<i}, dan tidak menggabungkan potongan cat yang memiliki status pohon properti yang diharapkan berubah pada thread compositor, seperti pada scroll thread compositor atau animasi transformasi thread compositor.
Contoh sebelumnya idealnya harus menghasilkan dua lapisan gabungan:
- Lapisan gabungan 800x600 yang berisi perintah menggambar:
drawRectdengan ukuran 800x600 dan warna putihdrawRectdengan ukuran 100x100 di posisi 0,0 dan warna merah muda
- Lapisan gabungan 144x224 yang berisi perintah menggambar:
drawTextBlobdengan posisi 0,0 dan teks "Hello world"- terjemahkan 0,18
rotateZ(25deg)drawRectdengan ukuran 75x200 pada posisi 0,0 dan warna oranyedrawTextBlobdengan posisi 0,0 dan teks "Saya jatuh"
Jika pengguna men-scroll #scroll,
lapisan gabungan kedua dipindahkan, tetapi tidak diperlukan proses raster.
Misalnya, dari bagian sebelumnya tentang hierarki properti, ada enam bagian cat. Bersama dengan status hierarki properti (transformasi, klip, efek, scroll), yaitu:
- Latar belakang dokumen: scroll dokumen, klip dokumen, root, scroll dokumen.
- Sudut horizontal, vertikal, dan scroll untuk div (tiga bagian cat terpisah):
scroll dokumen, klip dokumen, blur
#one, scroll dokumen. - Iframe
#one: putar#one, klip scroll tambahan, buram#one, scroll div. - Iframe
#two: skala#two, klip dokumen, root, scroll dokumen.
Frame Compositor: permukaan, permukaan render, dan ubin tekstur GPU
Proses {i>browser<i} dan {i>render<i} mengelola rasterisasi konten, kemudian mengirimkan {i>frame compositor<i} ke proses Viz untuk presentasi ke layar. Frame Compositor menunjukkan cara merangkai konten raster bersama-sama dan menggambarnya secara efisien menggunakan GPU.
Kartu
Secara teori, proses {i>render<i} atau pengomposisi proses {i>browser<i} bisa merasterisasi {i>pixel<i} menjadi satu tekstur ukuran penuh area pandang perender dan mengirimkan tekstur tersebut ke Viz. Untuk menampilkannya, compositor tampilan hanya perlu menyalin piksel dari satu tekstur tersebut ke posisi yang sesuai di buffer frame (misalnya, layar). Namun, jika kompositor itu ingin memperbarui bahkan satu piksel yang diperlukan untuk meraster ulang area tampilan penuh dan mengirimkan tekstur baru ke Viz.
Sebagai gantinya, area pandang dibagi menjadi beberapa petak. Kotak tekstur GPU terpisah mendukung setiap ubin dengan piksel raster untuk sebagian area pandang. Perender kemudian dapat memperbarui setiap ubin atau bahkan cukup ubah posisi di layar untuk ubin yang ada. Misalnya, saat menggulir {i>website<i}, posisi ubin yang ada akan bergeser ke atas dan hanya sesekali ubin baru perlu diraster untuk konten yang jauh ke bawah halaman.
Empat dan permukaan
Kartu tekstur GPU adalah jenis quad khusus, yang merupakan nama yang bagus untuk satu kategori tekstur atau kategori lainnya. Quad mengidentifikasi tekstur input, dan menunjukkan cara mengubah serta menerapkan efek visual pada tekstur tersebut. Misalnya, kartu konten reguler memiliki transformasi yang menunjukkan posisi x dan y-nya di petak petak peta.
Ubin raster ini digabungkan dalam langkah render, yang merupakan daftar segi empat. Penerusan render tidak berisi informasi piksel apa pun; sebagai gantinya, terdapat petunjuk tentang tempat dan cara menggambar setiap kuadrat untuk menghasilkan {i>output<i} piksel yang diinginkan. Ada draw quad untuk setiap kartu tekstur GPU. Kompositor tampilan hanya perlu melakukan iterasi melalui daftar paha depan, menggambar masing-masing gambar dengan efek visual yang telah ditentukan, untuk menghasilkan output piksel yang diinginkan untuk penerusan render. Menyusun kuadrat gambar untuk penerusan render bisa dilakukan secara efisien di GPU, karena efek visual yang diizinkan dipilih dengan cermat yang dipetakan langsung ke fitur GPU.
Ada jenis kuadrat gambar tambahan di luar ubin raster. Misalnya, ada kuadrat gambar warna solid yang tidak didukung oleh tekstur sama sekali. atau gambar tekstur kuadrat untuk tekstur non-ubin seperti video atau kanvas.
Hal ini juga memungkinkan frame compositor menyematkan frame compositor lain. Misalnya, {i>compositor<i} browser menghasilkan {i>frame<i} compositor dengan UI browser, dan persegi panjang kosong tempat konten compositor render akan disematkan. Contoh lainnya adalah iframe yang terisolasi situs. Penyematan ini dilakukan melalui permukaan.
Ketika compositor mengirimkan {i>frame<i} compositor, hal itu disertai dengan sebuah pengenal, yang disebut surface ID, yang memungkinkan frame compositor lain menyematkannya melalui referensi. Frame compositor terbaru yang dikirimkan dengan ID platform tertentu disimpan oleh Viz. Frame compositor lain kemudian dapat merujuknya nanti melalui kuadrat gambar permukaan, dan karena itu Viz tahu apa yang harus digambar. (Perhatikan bahwa kuadrat gambar permukaan hanya berisi ID permukaan, dan bukan tekstur.)
Penerusan render menengah
Beberapa efek visual, seperti banyak filter atau mode perpaduan lanjutan, mengharuskan dua kuadrat atau lebih digambar pada tekstur perantara. Kemudian tekstur perantara digambar ke buffer tujuan di GPU (atau mungkin tekstur perantara lainnya), menerapkan efek visual pada saat yang sama. Untuk memungkinkan hal ini, bingkai compositor sebenarnya berisi daftar penerusan render. Selalu ada penerusan render root, yang digambar terakhir dan yang tujuannya sesuai dengan {i>buffer <i}frame, dan mungkin ada lebih banyak lagi.
Kemungkinan beberapa penerusan render menjelaskan nama "render pass". Setiap penerusan harus dieksekusi secara berurutan di GPU, dalam beberapa "pass", sedangkan satu penerusan dapat diselesaikan dalam satu komputasi GPU paralel yang masif.
Agregasi
Beberapa {i>frame<i} compositor dikirimkan ke Viz, dan keduanya harus digambar di layar bersama-sama. Hal ini dilakukan dengan fase agregasi yang mengubahnya menjadi satu, {i>aggregated compositor frame<i} teragregasi. Agregasi menggantikan kuadrat gambar permukaan dengan frame compositor yang ditentukan. Ini juga merupakan peluang untuk mengoptimalkan tekstur perantara yang tidak perlu atau konten yang ada di balik layar. Misalnya, dalam banyak kasus, bingkai compositor untuk iframe yang diisolasi situs tidak memerlukan tekstur perantaranya sendiri, dan bisa digambar langsung ke dalam buffer frame melalui kuadrat gambar yang sesuai. Fase agregasi mencari tahu pengoptimalan tersebut dan menerapkannya berdasarkan pengetahuan global yang tidak dapat diakses oleh setiap compositor render.
Contoh
Berikut adalah {i>frame<i} compositor yang mewakili contoh dari awal postingan ini.
- Platform
foo.com/index.html: id=0- Penerusan render 0: menggambar ke output.
- Render pass draw quad: menggambar dengan blur 3 px dan diklip ke penerusan render 0.
- Penerusan render 1:
- Gambar segiempat untuk konten kartu iframe
#one, dengan posisi x dan y untuk masing-masing.
- Gambar segiempat untuk konten kartu iframe
- Penerusan render 1:
- Permukaan gambar quad: dengan ID 2, digambar dengan transformasi skala dan terjemahan.
- Render pass draw quad: menggambar dengan blur 3 px dan diklip ke penerusan render 0.
- Penerusan render 0: menggambar ke output.
- Platform UI browser: ID=1
- Penerusan render 0: menggambar ke output.
- Menggambar segi empat untuk UI browser (juga bersusun)
- Penerusan render 0: menggambar ke output.
- Platform
bar.com/index.html: ID=2- Penerusan render 0: menggambar ke output.
- Gambar segiempat untuk konten iframe
#two, dengan posisi x dan y untuk masing-masing.
- Gambar segiempat untuk konten iframe
- Penerusan render 0: menggambar ke output.
Ilustrasi oleh Una Kravets.