Halaman ini diterjemahkan oleh Cloud Translation API.

Struktur data utama dalam RenderingNG

Chris Harrelson

Daniel Cheng

Philip Rogers

Koji Ishi

Ian Kilpatrick

Kyle Charbonneau

Mari kita lihat struktur data utama, yang merupakan input dan output untuk pipeline rendering.

Struktur data ini adalah:

Hierarki frame terdiri dari node lokal dan jarak jauh yang mewakili dokumen web tempat dalam proses render dan perender Blink mana.
Hierarki fragmen yang tidak dapat diubah merepresentasikan output (dan input ke) algoritma batasan tata letak.
Hierarki properti mewakili transformasi, klip, efek, dan hierarki scroll dokumen web. Ini digunakan di seluruh pipeline.
Daftar tampilan dan potongan cat adalah input untuk algoritma raster dan layerization.
Frame Compositor mengenkapsulasi platform, permukaan render, dan kartu tekstur GPU yang digunakan untuk menggambar menggunakan GPU.

Sebelum membahas struktur data ini, contoh berikut dibuat berdasarkan peninjauan arsitektur. Contoh ini digunakan di seluruh dokumen ini dengan menunjukkan bagaimana struktur data berlaku untuknya.

<!-- 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 render yang berbeda dari frame induknya.

Dalam kode contoh, total ada tiga frame:

Frame induk foo.com, yang berisi dua iframe.

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:

Dua pohon bingkai yang mewakili kedua proses render.

Frame yang dirender dalam proses berbeda direpresentasikan sebagai frame jarak jauh. Frame jarak jauh menyimpan informasi minimum yang diperlukan untuk bertindak sebagai placeholder dalam rendering, seperti dimensinya. Jika tidak, frame jarak jauh tidak berisi informasi apa pun yang diperlukan untuk merender kontennya yang sebenarnya.

Sebaliknya, frame lokal mewakili frame yang melewati pipeline rendering standar. Frame lokal berisi semua informasi yang diperlukan untuk mengubah data frame 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, kini ada tiga fragmen hierarki frame lokal, dengan dua dalam proses render untuk foo.com dan satu dalam proses rendering untuk bar.com:

Representasi dua render, dan tiga fragmen hierarki frame.

Untuk menghasilkan satu frame compositor untuk halaman web, Viz secara bersamaan meminta frame compositor dari frame root masing-masing tiga pohon frame lokal, lalu menggabungkannya. Lihat juga bagian frame compositor.

Frame utama foo.com dan subframe foo.com/other-page adalah bagian dari hierarki frame yang sama dan dirender dalam proses yang sama. Namun, kedua frame tersebut masih memiliki siklus proses dokumen independen 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 render tidak memiliki cukup informasi 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 tampilan 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 akan diterapkan ke widget frame utama sebelum diterapkan ke widget yang tersisa dari atas ke bawah.

Misalnya, saat ukuran area pandang berubah:

Diagram proses yang dijelaskan dalam teks sebelumnya.

Proses ini tidak instan, sehingga properti visual yang direplikasi juga menyertakan token sinkronisasi. Kompositor Viz menggunakan token sinkronisasi ini untuk menunggu semua fragmen hierarki frame lokal mengirimkan frame 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 pipeline rendering. Elemen ini mewakili posisi dan ukuran semua elemen di halaman (tanpa penerapan transformasi).

Representasi fragmen di setiap hierarki, dengan satu fragmen ditandai sebagai memerlukan tata letak.

Setiap fragmen mewakili bagian dari elemen DOM. Biasanya hanya ada satu fragmen per elemen, tetapi bisa lebih jika dibagi menjadi beberapa halaman yang berbeda saat mencetak, atau kolom saat dalam 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 setiap referensi "atas" dalam hierarki. (Turunan tidak dapat memiliki pointer ke induknya.)
data "gelembung" ke bawah pohon (turunan 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 merupakan update inkremental, misalnya, aplikasi web yang mengupdate sebagian kecil UI sebagai respons terhadap pengguna yang mengklik 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.

Pada masa mendatang, 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 menjalankan fase berikutnya di thread yang berbeda), membuat beberapa hierarki untuk animasi tata letak yang lancar, 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. Daripada struktur pohon dengan kotak dan pointer, kami merepresentasikan konten inline dalam daftar datar yang mewakili hierarki tersebut. Manfaat utamanya adalah representasi daftar datar untuk inline dapat dilakukan dengan cepat, berguna untuk memeriksa atau membuat kueri 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 mendalam yang pertama pada 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 "there".

Saat konteks pemformatan inline untuk situasi ini direpresentasikan sebagai hierarki, 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 API geometri 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 merupakan daftar datar, penelusuran depth-first hanya menambah offset array, sehingga memberikan iterasi yang cepat dan lokalitas memori.
Fungsi ini menyediakan penelusuran luas-pertama, yang diperlukan saat, misalnya, melukis latar belakang garis dan kotak inline.
Mengetahui jumlah turunan akan mempercepat perpindahan ke pasangan berikutnya (cukup tambahkan offset array dengan angka tersebut).

Hierarki properti

DOM adalah hierarki elemen (plus node teks), dan CSS dapat menerapkan berbagai gaya ke elemen.

Hal ini muncul dalam empat cara:

Tata letak: input ke algoritme batasan tata letak.
Paint: cara melukis dan raster elemen (tetapi bukan turunannya).
Visual: efek raster/gambar yang diterapkan ke subhierarki DOM, seperti transformasi, filter, dan kliping.
Scrolling: pemotongan sudut rata sumbu dan membulat dan scroll subpohon yang terdapat di dalamnya.

Pohon properti adalah struktur data yang menjelaskan bagaimana efek visual dan scroll diterapkan pada elemen DOM. Keduanya menyediakan cara untuk menjawab pertanyaan seperti: di mana, sesuai dengan layar, merupakan 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. Jadi, hal terpenting yang dilakukan hierarki properti adalah menerjemahkan kompleksitas tersebut menjadi satu struktur data yang merepresentasikan struktur dan maknanya dengan tepat, sekaligus menghilangkan kerumitan DOM dan CSS lainnya. Ini memungkinkan kita menerapkan algoritma untuk komposisi dan scroll dengan lebih percaya diri. Pada khususnya:

Geometri yang berpotensi mengalami error dan penghitungan lainnya dapat dipusatkan di satu tempat.
Kompleksitas pembuatan dan pembaruan hierarki properti diisolasi menjadi satu tahap pipeline rendering.
Akan jauh lebih mudah dan lebih cepat untuk mengirim hierarki properti ke berbagai thread dan proses daripada status DOM lengkap, sehingga Anda dapat menggunakannya untuk banyak kasus penggunaan.
Semakin banyak kasus penggunaan, semakin banyak hasil yang dapat diperoleh dari cache geometri yang dibangun di atas, karena cache tersebut dapat digunakan kembali oleh cache satu sama lain.

RenderingNG menggunakan hierarki properti untuk berbagai tujuan, termasuk:

Memisahkan komposisi dari cat, dan mengomposisikan dari utas utama.
Menentukan strategi penyusunan / menggambar yang optimal.
Mengukur geometri IntersectionObserver.
Menghindari pekerjaan untuk elemen di luar layar dan ubin tekstur GPU.
Membatalkan validasi cat dan raster secara efisien dan akurat.
Mengukur pergeseran tata letak dan largest contentful paint di Core Web Vitals.

Setiap dokumen web memiliki empat hierarki properti terpisah: transformasi, klip, efek, dan scroll.(*) Hierarki transformasi mewakili transformasi dan scroll CSS. (Transformasi scroll direpresentasikan sebagai matriks transformasi 2D.) Hierarki klip menampilkan klip tambahan. Hierarki efek mewakili semua efek visual lainnya: opasitas, filter, mask, mode campuran, dan jenis klip lainnya seperti jalur klip. Hierarki scroll mewakili informasi tentang scroll, seperti cara men-scroll rantai secara bersamaan; diperlukan untuk melakukan scroll pada thread compositor. Tiap node dalam hierarki properti mewakili scroll atau efek visual yang diterapkan oleh elemen DOM. Jika memiliki beberapa efek, mungkin akan ada lebih dari satu node hierarki 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, akan ada tiga node hierarki klip, dan struktur hierarki klip akan mengikuti hubungan blok yang memuat antara klip tambahan. Terdapat tautan di antara pohon-pohon tersebut. Link ini menunjukkan hierarki DOM relatif, beserta urutan penerapan node. Misalnya, jika transformasi pada elemen DOM berada di bawah elemen DOM lain yang memiliki filter, tentunya transformasi tersebut akan diterapkan sebelum filter.

Setiap elemen DOM memiliki status hierarki properti, yaitu 4 tuple (transformasi, klip, efek, scroll) yang menunjukkan node hierarki, transformasi, dan klip ancestor terdekat yang berlaku pada elemen tersebut. Cara ini sangat mudah, karena dengan informasi ini kami dapat mengetahui dengan pasti daftar klip, transformasi, dan efek yang berlaku untuk elemen tersebut, beserta urutannya. Ini memberi tahu kita letaknya di layar dan cara menggambarnya.

Catatan: (*) Ada empat pohon karena scroll hanya berlaku untuk subhierarki yang dimuat. Sebuah elemen dimuat oleh scroller jika di-scroll bersama elemen tersebut, serta elemen position:absolute dan position: fixed sering meng-escape elemen scroll ancestor, dalam situasi saat elemen scroll tidak berada dalam rantai blok yang memuatnya (rantai blok yang memuat elemen DOM adalah blok yang memuatnya, serta blok yang memuatnya, dan seterusnya hingga elemen root), secara berulang) dari elemen yang ditempatkan tetap atau absolut. Namun, semua efek visual lainnya berlaku untuk seluruh subhierarki DOM. Karena ketidakcocokan ini, topologi aspek kliping dan scroll hierarki properti terkadang sangat berbeda dari efek visual. Inilah alasan mengapa sebagian besar efek visual menginduksi blok yang berisi untuk semua turunan (contoh). Struktur lengkap hierarki properti cukup rumit. Lihat komentar kode panjang di sini untuk mengetahui informasi tentang subjek ini.

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 pada pendahuluan), berikut adalah elemen utama dari hierarki properti yang dihasilkan:

Contoh berbagai elemen dalam hierarki properti.

Menampilkan daftar dan potongan cat

Item tampilan berisi perintah gambar 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:

Kotak biru, dengan tulisan 'Halo dunia' di dalam persegi panjang hijau.

<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 pemberian 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. Elemen DOM tunggal dapat menghasilkan sejumlah item tampilan, seperti cara #green memiliki item tampilan untuk latar belakang dan item tampilan lainnya untuk teks inline. Perincian ini penting untuk merepresentasikan kompleksitas penuh spesifikasi urutan warna CSS, seperti interleaving yang dibuat oleh margin negatif:

Persegi panjang hijau, dengan kotak abu-abu yang sebagian dilapisi dan kata 'Halo dunia'.

<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 paint tree, item tampilannya akan disalin dari daftar sebelumnya. Pengoptimalan tambahan bergantung pada properti spesifikasi urutan cat CSS: konteks tumpukan melukis secara atomik. Jika tidak ada objek tata letak yang berubah dalam konteks penumpukan, jalur paint tree akan melewati 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 ke dalam "bagian" item tampilan yang memiliki status hierarki properti yang sama. Hal ini ditunjukkan dalam contoh berikut:

Kotak merah muda dengan kotak oranye miring.

<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):

Gambar tabel sebelumnya, dua sel pertama pada potongan 1, sel ketiga pada potongan 2, dan dua sel terakhir pada potongan 3.

Daftar urutan potongan paint, yang merupakan kelompok item tampilan dan status hierarki properti, merupakan input untuk langkah pelapisan pada pipeline rendering. Seluruh daftar potongan cat dapat digabungkan menjadi satu lapisan gabungan dan diraster, tetapi cara ini akan memerlukan proses raster yang mahal setiap kali pengguna men-scroll. Lapisan gabungan dapat dibuat untuk setiap bagian cat dan diraster satu per satu untuk menghindari semua proses raster ulang, tetapi akan dengan 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 default, dan tidak menggabungkan potongan cat yang memiliki status hierarki properti yang diharapkan berubah pada thread compositor, seperti dengan scroll thread compositor atau animasi transformasi thread compositor.

Contoh sebelumnya idealnya harus menghasilkan dua lapisan gabungan:

Lapisan gabungan berukuran 800x600 yang berisi perintah gambar:
1. drawRect dengan ukuran 800x600 dan warna putih
2. drawRect dengan ukuran 100x100 di posisi 0,0 dan warna merah muda
Lapisan gabungan berukuran 144x224 yang berisi perintah gambar:
1. drawTextBlob dengan posisi 0,0 dan teks "Hello world"
2. terjemahkan 0,18
3. rotateZ(25deg)
4. drawRect dengan ukuran 75x200 pada posisi 0,0 dan warna oranye
5. drawTextBlob dengan posisi 0,0 dan teks "Saya jatuh"

Jika pengguna men-scroll #scroll, lapisan gabungan kedua akan dipindahkan, tetapi proses rasterisasi tidak diperlukan.

Misalnya, dari bagian sebelumnya tentang hierarki properti, ada enam potongan 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 browser dan render mengelola rasterisasi konten, lalu mengirimkan frame compositor ke proses Viz untuk ditampilkan di layar. Frame kompositor menunjukkan cara merangkai konten raster dan menggambarnya secara efisien menggunakan GPU.

Kartu

Secara teori, proses render atau compositor proses browser dapat merasterisasi piksel 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 dalam buffer frame (misalnya, layar). Namun, jika compositor tersebut ingin memperbarui bahkan satu piksel saja, kompositor tersebut perlu raster 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 kartu atau bahkan mengubah posisi di layar untuk kartu yang ada. Misalnya, saat men-scroll situs, posisi kotak yang ada akan bergeser ke atas dan hanya terkadang kartu baru perlu diraster untuk konten di bagian bawah halaman.

Empat ubin. — Gambar ini menunjukkan gambar hari yang cerah, dengan empat ubin. Saat scroll terjadi, kotak kelima mulai muncul. Salah satu kotak hanya memiliki satu warna (biru langit), dan ada video serta iframe di atasnya.

Empat dan permukaan

Kartu tekstur GPU adalah jenis quad khusus, yang merupakan nama khusus 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.

Petak tekstur GPU.

Ubin raster ini digabungkan dalam langkah render, yang merupakan daftar segi empat. Render pass tidak berisi informasi piksel apa pun; sebaliknya, render pass memiliki petunjuk tempat dan cara menggambar setiap segiempat untuk menghasilkan output piksel yang diinginkan. Ada draw quad untuk setiap kartu tekstur GPU. Kompositor tampilan hanya perlu melakukan iterasi melalui daftar segi empat, yang menggambar masing-masing dengan efek visual yang ditentukan, untuk menghasilkan output piksel yang diinginkan untuk penerusan render. Menyusun kuadrat gambar untuk penerusan render dapat dilakukan secara efisien di GPU, karena efek visual yang diizinkan dipilih dengan cermat sebagai efek 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 kuadrat gambar tekstur untuk tekstur non-kartu seperti video atau kanvas.

Hal ini juga memungkinkan frame compositor menyematkan frame compositor lain. Misalnya, compositor browser menghasilkan frame 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.

Saat mengirimkan frame compositor, compositor disertai dengan ID, yang disebut ID permukaan, sehingga 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, sehingga 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 campuran lanjutan, mengharuskan dua atau lebih kuadrat digambar pada tekstur perantara. Kemudian, tekstur perantara digambar ke buffer tujuan di GPU (atau mungkin tekstur perantara lainnya), dengan 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 buffer frame, dan mungkin masih banyak lagi.

Kemungkinan beberapa penerusan render menjelaskan nama "pass render". Setiap penerusan harus dijalankan secara berurutan di GPU, dalam beberapa "pass", sedangkan satu penerusan dapat diselesaikan dalam satu komputasi GPU paralel yang sangat besar.

Agregasi

Beberapa frame compositor dikirim ke Viz, dan harus digambar ke layar bersama-sama. Hal ini dilakukan dengan fase agregasi yang mengubahnya menjadi satu frame compositor gabungan. 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, frame compositor untuk iframe yang terisolasi situs tidak memerlukan tekstur perantaranya sendiri, dan dapat digambar langsung ke buffer frame melalui kuadrat gambar yang sesuai. Fase agregasi mengetahui pengoptimalan tersebut dan menerapkannya berdasarkan pengetahuan global yang tidak dapat diakses oleh compositor render individual.

Contoh

Berikut adalah frame 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.
  - Permukaan gambar quad: dengan ID 2, digambar dengan transformasi skala dan terjemahan.
Platform UI browser: ID=1
- Penerusan render 0: menggambar ke output.
  - Menggambar segi empat untuk UI browser (juga bersusun)
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.

Ilustrasi oleh Una Kravets.