Arsitektur RenderingNG

Di sini Anda akan menemukan cara menyiapkan bagian-bagian komponen RenderingNG, dan cara pipeline rendering mengalir melaluinya.

Mulai dari level tertinggi, tugas rendering adalah:

1. Merender konten ke dalam piksel di layar.
2. Menganimasikan efek visual pada konten dari satu status ke status lainnya.
3. Scroll untuk merespons input.
4. Rutekan input secara efisien ke tempat yang tepat sehingga skrip developer dan subsistem lainnya dapat merespons.

Konten yang akan dirender adalah hierarki frame untuk setiap tab browser, ditambah antarmuka browser. Dan, aliran peristiwa input mentah dari layar sentuh, mouse, keyboard, dan perangkat hardware lainnya.

Setiap frame mencakup:

• Status DOM
• CSS
• Kanvas
• Referensi eksternal, seperti gambar, video, font, dan SVG

Frame adalah dokumen HTML beserta URL-nya. Halaman web yang dimuat di tab browser memiliki frame tingkat atas, frame turunan untuk setiap iframe yang disertakan dalam dokumen tingkat atas, dan turunan iframe rekursifnya.

Efek visual adalah operasi grafis yang diterapkan pada bitmap, seperti scroll, transformasi, klip, filter, opasitas, atau gabungan.

Komponen arsitektur

Dalam RenderingNG, tugas ini dibagi secara logis ke dalam beberapa tahap dan komponen kode. Komponen tersebut berakhir di berbagai proses, thread, dan subkomponen CPU di dalam thread tersebut. Masing-masing peran penting dalam mencapai keandalan, performa skalabel, dan ekstensibilitas untuk semua konten web.

Struktur pipeline rendering

Rendering berjalan di pipeline dengan sejumlah tahap dan artefak yang dibuat di sepanjang prosesnya. Setiap tahap merepresentasikan kode yang melakukan satu tugas yang didefinisikan dengan baik dalam rendering. Artefak adalah struktur data yang merupakan input atau output tahapan.

Tahapannya adalah:

1. Animasikan: mengubah gaya komputasi dan memutasikan hierarki properti dari waktu ke waktu berdasarkan linimasa deklaratif.
2. Gaya: menerapkan CSS ke DOM, dan membuat gaya komputasi.
3. Tata letak: menentukan ukuran dan posisi elemen DOM di layar, dan membuat hierarki fragmen yang tidak dapat diubah.
4. Pra-lukis: menghitung hierarki properti dan membatalkan validasi daftar tampilan dan kartu tekstur GPU yang ada.
5. Scroll: memperbarui offset scroll dokumen dan elemen DOM yang dapat di-scroll, dengan mengubah hierarki properti.
6. Paint: menghitung daftar tampilan yang menjelaskan cara melakukan raster ubin tekstur GPU dari DOM.
7. Commit: menyalin hierarki properti dan daftar tampilan ke thread compositor.
8. Membuat lapisan: membagi daftar tampilan menjadi daftar lapisan gabungan untuk proses raster dan animasi independen.
9. Worklet raster, dekode, dan paint: mengubah daftar tampilan, gambar yang dienkode, dan kode worklet cat, secara berurutan, menjadi kartu tekstur GPU.
10. Aktifkan: buat frame compositor yang mewakili cara menggambar dan memosisikan kartu GPU ke layar, bersama dengan efek visual apa pun.
11. Agregat: menggabungkan frame compositor dari semua frame compositor yang terlihat menjadi satu frame compositor global.
12. Draw: mengeksekusi frame compositor gabungan pada GPU untuk membuat piksel di layar.

Tahapan pipeline rendering dapat dilewati jika tidak diperlukan. Misalnya, animasi efek visual, dan scroll, bisa melewati tata letak, pra-lukis, dan menggambar. Inilah sebabnya animasi dan scroll ditandai dengan titik kuning dan hijau pada diagram. Jika tata letak, pre-Paint, dan Paint dapat dilewati untuk efek visual, semua itu dapat dijalankan sepenuhnya di thread compositor dan melewati thread utama.

Rendering UI browser tidak digambarkan secara langsung di sini, tetapi dapat dianggap sebagai versi sederhana dari pipeline yang sama ini (dan bahkan penerapannya menggunakan banyak kode yang sama). Video (juga tidak digambarkan secara langsung) umumnya dirender dengan kode independen yang mendekode frame menjadi ubin tekstur GPU yang kemudian dihubungkan ke frame compositor dan langkah menggambar.

Struktur proses dan thread

Proses CPU

Penggunaan beberapa proses CPU mencapai performa dan isolasi keamanan antara situs dan dari status browser, serta stabilitas dan isolasi keamanan dari hardware GPU.

• Proses render merender, menganimasikan, men-scroll, dan merutekan input untuk satu kombinasi situs dan tab. Ada beberapa proses render.
• Proses browser merender, menganimasikan, dan merutekan input untuk UI browser (termasuk kolom URL, judul tab, dan ikon), serta mengarahkan semua input yang tersisa ke proses render yang sesuai. Hanya ada satu proses browser.
• Proses Viz menggabungkan komposisi dari beberapa proses render plus proses browser. Pola ini melakukan raster dan menggambar menggunakan GPU. Ada satu proses {i>Viz<i}.

Situs yang berbeda selalu berakhir di proses render yang berbeda.

Beberapa tab atau jendela browser dari situs yang sama biasanya masuk dalam proses render yang berbeda, kecuali jika tab tersebut berkaitan, seperti satu membuka tab lainnya. Di bawah tekanan memori yang kuat pada desktop, Chromium dapat menempatkan beberapa tab dari situs yang sama ke dalam proses render yang sama meskipun tidak terkait.

Dalam satu tab browser, frame dari situs yang berbeda selalu berada dalam proses render yang berbeda satu sama lain, tetapi frame dari situs yang sama selalu dalam proses render yang sama. Dari perspektif rendering, keuntungan penting dari beberapa proses render adalah bahwa iframe dan tab lintas situs mencapai isolasi performa satu sama lain. Selain itu, origin dapat memilih untuk melakukan isolasi lebih lanjut.

Hanya ada satu proses Viz untuk semua Chromium, karena biasanya hanya ada satu GPU dan layar untuk menggambar.

Memisahkan Viz ke dalam prosesnya sendiri bagus untuk stabilitas dalam menghadapi bug di driver atau hardware GPU. Vulkan juga bagus untuk isolasi keamanan, yang penting untuk API GPU seperti Vulkan dan keamanan secara umum.

Karena browser dapat memiliki banyak tab dan jendela, dan semuanya memiliki piksel UI browser untuk digambar, Anda mungkin bertanya-tanya: mengapa hanya ada satu proses browser? Alasannya adalah hanya salah satunya yang difokuskan pada satu waktu; kenyataannya, tab browser yang tidak terlihat sebagian besar dinonaktifkan dan melepaskan semua memori GPU-nya. Namun, fitur rendering UI browser yang kompleks kini makin banyak diterapkan dalam proses render (juga dikenal sebagai WebUI). Hal ini bukanlah untuk alasan isolasi performa, tetapi untuk memanfaatkan kemudahan penggunaan mesin rendering web Chromium.

Di perangkat Android lama, proses render dan browser dibagikan saat digunakan di WebView (ini tidak berlaku untuk Chromium di Android secara umum, hanya WebView). Di WebView, proses browser juga dibagikan ke aplikasi penyematan, dan WebView hanya memiliki satu proses render.

Terkadang juga terdapat proses utilitas untuk mendekode konten video yang dilindungi. Proses ini tidak digambarkan dalam diagram sebelumnya.

Rangkaian percakapan

Thread membantu mencapai isolasi dan responsivitas performa meskipun tugas berjalan lambat, paralelisasi pipeline, dan beberapa buffering.

• Thread utama menjalankan skrip, loop peristiwa rendering, siklus proses dokumen, hit testing, pengiriman peristiwa skrip, dan penguraian HTML, CSS, dan format data lainnya.
  • Helper thread utama melakukan tugas seperti membuat bitmap dan blob gambar yang memerlukan encoding atau decoding.
  • Web Worker menjalankan skrip, dan loop peristiwa rendering untuk OffscreenCanvas.
• Thread Compositor memproses peristiwa input, menjalankan scroll dan animasi konten web, menghitung layerisasi konten web yang optimal, serta mengoordinasikan dekode gambar, worklet cat, dan tugas raster.
  • Bantuan thread kompositor mengoordinasikan tugas raster Viz, dan menjalankan tugas dekode gambar, worklet cat, dan raster fallback.
• Thread media, demuxer, atau output audio mendekode, memproses, dan menyinkronkan streaming video dan audio. (Ingat bahwa video dijalankan secara paralel dengan pipeline rendering utama.)

Memisahkan thread utama dan compositor sangat penting untuk isolasi performa animasi dan scroll dari tugas thread utama.

Hanya ada satu thread utama per proses render, meskipun beberapa tab atau frame dari situs yang sama mungkin berakhir dalam proses yang sama. Namun, terdapat isolasi performa dari pekerjaan yang dilakukan di berbagai API browser. Misalnya, pembuatan bitmap dan blob gambar di Canvas API berjalan di thread bantuan thread utama.

Demikian juga, hanya ada satu thread compositor per proses render. Umumnya bukan masalah jika hanya ada satu, karena semua operasi yang sangat mahal di thread compositor didelegasikan ke thread pekerja compositor atau proses Viz, dan pekerjaan ini dapat dilakukan secara paralel dengan perutean input, scroll, atau animasi. Thread pekerja Compositor mengoordinasikan tugas yang berjalan dalam proses Viz, tetapi akselerasi GPU di mana saja dapat gagal karena alasan di luar kontrol Chromium, seperti bug driver. Dalam situasi ini, thread pekerja akan melakukan pekerjaan dalam mode fallback pada CPU.

Jumlah thread pekerja compositor bergantung pada kemampuan perangkat. Misalnya, desktop umumnya akan menggunakan lebih banyak thread, karena memiliki lebih banyak inti CPU dan lebih hemat baterai dibandingkan perangkat seluler. Ini adalah contoh dari peningkatan dan penurunan skala.

Arsitektur threading proses render adalah penerapan dari tiga pola pengoptimalan yang berbeda:

• Thread helper: mengirimkan subtugas yang berjalan lama ke thread tambahan agar thread induk tetap responsif terhadap permintaan simultan lainnya. Thread helper dan compositor thread utama adalah contoh yang baik dari teknik ini.
• Beberapa buffering: menampilkan konten yang dirender sebelumnya saat merender konten baru, untuk menyembunyikan latensi rendering. Thread compositor menggunakan teknik ini.
• Paralelisasi pipeline: menjalankan pipeline rendering di beberapa tempat secara bersamaan. Berikut cara scroll dan animasi berjalan cepat; meskipun update rendering thread utama terjadi, scroll dan animasi dapat berjalan secara paralel.

Proses browser

• Thread render dan pengomposisian merespons input di UI browser, mengarahkan input lain ke proses render yang benar; menyusun dan melukiskan UI browser.
• Helper thread render dan pengomposisian menjalankan tugas dekode gambar dan raster atau dekode penggantian.

Thread render dan pengomposisian proses browser mirip dengan kode dan fungsi proses render, kecuali bahwa thread utama dan thread compositor digabungkan menjadi satu. Hanya ada satu thread yang diperlukan dalam kasus ini karena tidak perlu pengisolasian performa dari tugas thread utama yang panjang, karena tidak ada yang sengaja dibuat.

Proses Viz

• Raster Thread utama GPU menampilkan daftar dan frame video ke dalam ubin tekstur GPU, serta menggambar frame compositor ke layar.
• Thread compositor tampilan menggabungkan dan mengoptimalkan komposisi dari setiap proses render, plus proses browser, ke dalam satu frame compositor untuk ditampilkan di layar.

Proses menggambar raster dan menggambar umumnya terjadi pada thread yang sama, karena keduanya bergantung pada resource GPU, dan sulit untuk menggunakan GPU multi-thread secara andal (akses multi-thread yang lebih mudah ke GPU adalah salah satu motivasi untuk mengembangkan standar Vulkan baru). Di Android WebView, ada thread render tingkat OS yang terpisah untuk menggambar karena cara WebView disematkan ke aplikasi native. Platform lain mungkin akan memiliki thread seperti itu di masa mendatang.

Kompositor tampilan berada di thread yang berbeda karena harus selalu responsif, dan tidak memblokir kemungkinan sumber pelambatan di thread utama GPU. Salah satu penyebab pelambatan pada thread utama GPU adalah panggilan ke kode non-Chromium, seperti driver GPU khusus vendor, yang mungkin lambat sehingga sulit diprediksi.

Struktur komponen

Dalam setiap thread utama atau compositor proses render, ada komponen software logis yang berinteraksi satu sama lain secara terstruktur.

Komponen thread utama proses render

Di Perender Blink:

• Fragmen hierarki frame lokal mewakili hierarki frame lokal dan DOM dalam frame.
• Komponen DOM dan Canvas API berisi implementasi dari semua API ini.
• Runner siklus proses dokumen menjalankan langkah-langkah pipeline rendering hingga dan termasuk langkah commit.
• Komponen hit testing dan pengiriman peristiwa input menjalankan hit test untuk mencari tahu elemen DOM mana yang ditargetkan oleh peristiwa, dan menjalankan algoritma pengiriman peristiwa input serta perilaku default.

Penjadwal dan runner loop peristiwa rendering menentukan apa yang akan dijalankan di loop peristiwa dan waktunya. Fungsi ini menjadwalkan rendering agar terjadi pada ritme yang cocok dengan tampilan perangkat.

Fragmen hierarki frame lokal sedikit rumit. Mengingat kembali bahwa hierarki frame adalah halaman utama dan iframe turunannya, secara berulang. Frame bersifat lokal untuk proses render jika dirender dalam proses tersebut, dan jika tidak, frame akan berjalan jauh.

Anda bisa membayangkan mewarnai {i>frame<i} sesuai dengan proses rendernya. Pada gambar sebelumnya, lingkaran hijau merupakan frame dalam satu proses render; lingkaran oranye dalam proses render kedua, dan yang biru berada di proses ketiga.

Fragmen hierarki frame lokal adalah komponen terhubung dari warna yang sama dalam hierarki frame. Ada empat pohon frame lokal dalam gambar: dua untuk situs A, satu untuk situs B, dan satu untuk situs C. Setiap hierarki frame lokal mendapatkan komponen perender Blink-nya sendiri. Perender Blink hierarki frame lokal mungkin berada dalam proses render yang sama dengan hierarki frame lokal lainnya, mungkin juga tidak. Hal ini ditentukan oleh cara pemilihan proses render, seperti yang dijelaskan sebelumnya.

Struktur thread kompositor proses render

Komponen kompositor proses render meliputi:

• Pengendali data yang mengelola daftar lapisan gabungan, daftar tampilan, dan hierarki properti.
• Runner siklus proses yang menjalankan animasi, scroll, komposit, raster, serta mendekode dan mengaktifkan langkah-langkah pipeline rendering. (Ingat bahwa animasi dan scroll dapat terjadi di thread utama dan compositor.)
• Pengendali input dan hit test melakukan pemrosesan input dan uji hit pada resolusi lapisan gabungan, untuk menentukan apakah gestur scroll dapat dijalankan pada thread compositor, dan hit test proses render mana yang harus ditargetkan.

Contoh arsitektur dalam praktik

Dalam contoh ini ada tiga tab:

Tab 1: foo.com

<html>
  <iframe id=one src="foo.com/other-url"></iframe>
  <iframe  id=two src="bar.com"></iframe>
</html>

Tab 2: bar.com

<html>
 …
</html>

Tab 3: baz.com html <html> … </html>

Struktur proses, thread, dan komponen untuk tab ini terlihat seperti berikut:

Mari kita pelajari satu contoh masing-masing dari empat tugas utama rendering. Pengingat:

1. Render konten menjadi piksel di layar.
2. Menganimasikan efek visual pada konten dari satu status ke status lainnya.
3. Scroll untuk merespons input.
4. Rutekan input secara efisien ke tempat yang tepat sehingga skrip developer dan subsistem lainnya dapat merespons.

Untuk merender DOM yang diubah untuk tab satu:

1. Skrip developer mengubah DOM dalam proses render untuk foo.com.
2. Perender Blink memberi tahu compositor bahwa render perlu dilakukan.
3. Kompositor memberi tahu Viz bahwa diperlukan render agar terjadi.
4. Viz menandakan dimulainya {i>render<i} kembali ke compositor.
5. Kompositor meneruskan sinyal awal ke perender Berkedip.
6. Runner loop peristiwa thread utama menjalankan siklus proses dokumen.
7. Thread utama mengirimkan hasil ke thread compositor.
8. Runner loop peristiwa compositor menjalankan siklus proses pengomposisian.
9. Tugas raster apa pun dikirim ke Viz untuk raster (sering kali ada lebih dari satu tugas ini).
10. Viz mengubah konten di GPU.
11. Viz mengakui penyelesaian tugas raster. Catatan: Chromium sering kali tidak menunggu raster selesai, dan sebagai gantinya menggunakan sesuatu yang disebut token sinkronisasi yang harus diselesaikan dengan tugas raster sebelum langkah 15 dijalankan.
12. {i>Frame compositor<i} dikirim ke Viz.
13. Viz menggabungkan frame compositor untuk proses render foo.com, proses render iframe bar.com, dan UI browser.
14. Viz menjadwalkan undian.
15. Viz menggambar {i>frame<i} compositor teragregasi ke layar.

Untuk menganimasikan transisi transformasi CSS di tab dua:

1. Thread compositor untuk proses render bar.com mencentang animasi dalam loop peristiwa compositor dengan mengubah hierarki properti yang ada. Ini kemudian menjalankan kembali siklus hidup compositor. (Tugas raster dan dekode dapat terjadi, tetapi tidak digambarkan di sini.)
2. {i>Frame compositor<i} dikirim ke Viz.
3. Viz menggabungkan bingkai compositor untuk proses render foo.com, proses render bar.com, dan UI browser.
4. Viz menjadwalkan undian.
5. Viz menggambar {i>frame<i} compositor teragregasi ke layar.

Untuk men-scroll halaman web di tab tiga:

1. Urutan peristiwa input (mouse, sentuh, atau keyboard) muncul pada proses browser.
2. Setiap peristiwa dirutekan ke thread compositor proses render baz.com.
3. Compositor menentukan apakah thread utama perlu mengetahui tentang peristiwa tersebut.
4. Peristiwa ini akan dikirim, jika perlu, ke thread utama.
5. Thread utama mengaktifkan pemroses peristiwa input (pointerdown, touchstar, pointermove, touchmove, atau wheel) untuk melihat apakah pemroses akan memanggil preventDefault pada peristiwa tersebut atau tidak.
6. Thread utama menampilkan apakah preventDefault dipanggil ke compositor.
7. Jika tidak, peristiwa input akan dikirim kembali ke proses browser.
8. Proses browser mengonversinya menjadi gestur scroll dengan menggabungkannya dengan peristiwa terbaru lainnya.
9. {i>Gesture scroll <i}akan dikirim sekali lagi ke utas kompositor proses render baz.com,
10. Scroll diterapkan di sana, dan thread compositor untuk proses render bar.com mencentang animasi dalam loop peristiwa compositor-nya. Tindakan ini kemudian mengubah offset scroll di hierarki properti dan menjalankan ulang siklus proses compositor. Kode ini juga memberi tahu thread utama untuk mengaktifkan peristiwa scroll (tidak digambarkan di sini).
11. {i>Frame compositor<i} dikirim ke Viz.
12. Viz menggabungkan frame compositor untuk proses render foo.com, proses render bar.com, dan UI browser.
13. Viz menjadwalkan undian.
14. Viz menggambar {i>frame<i} compositor teragregasi ke layar.

Untuk merutekan peristiwa click di hyperlink di iframe #two di tab satu:

1. Peristiwa input (mouse, sentuh, atau keyboard) muncul pada proses browser. Alat ini melakukan perkiraan hit test untuk menentukan bahwa proses render iframe bar.com akan menerima klik, lalu mengirimkannya ke sana.
2. Thread compositor untuk bar.com mengarahkan peristiwa click ke thread utama untuk bar.com dan menjadwalkan tugas loop peristiwa rendering untuk memprosesnya.
3. Pemroses peristiwa input untuk hit test thread utama bar.com guna menentukan elemen DOM di iframe yang diklik, dan mengaktifkan peristiwa click untuk diamati oleh skrip. Tidak mendengar preventDefault, fungsi ini akan membuka hyperlink.
4. Setelah halaman tujuan hyperlink dimuat, status baru akan dirender, dengan langkah-langkah yang mirip dengan contoh "rendering DOM yang diubah" sebelumnya. (Perubahan berikutnya ini tidak digambarkan di sini.)

Bawa pulang

Butuh banyak waktu untuk mengingat dan menginternalisasi cara kerja rendering.

Intisarinya yang paling penting adalah pipeline rendering, melalui modularisasi yang cermat dan perhatian terhadap detail, telah dipecah menjadi sejumlah komponen mandiri. Komponen ini kemudian telah dibagi menjadi proses dan thread paralel untuk memaksimalkan performa skalabel dan peluang ekstensibilitas.

Setiap komponen memainkan peran penting dalam mengaktifkan performa dan fitur aplikasi web modern.

Terus baca tentang struktur data utama, yang sama pentingnya untuk RenderingNG seperti komponen kode.

---

Ilustrasi oleh Una Kravets.