Siap untuk konten web generasi berikutnya
RenderingNG adalah arsitektur rendering generasi berikutnya, yang jauh lebih baik dari sebelumnya. RenderingNG dibuat selama lebih dari delapan tahun dan mewakili pekerjaan kolektif dari banyak developer Chromium yang berdedikasi. API ini membuka sejumlah besar potensi untuk konten web yang cepat, lancar, andal, responsif, dan interaktif.
Di sini, Anda akan mempelajari apa yang kami buat, alasan kami membuatnya, dan cara kerjanya.
Sasaran bintang utara
Tujuan utama yang memotivasi RenderingNG adalah bahwa implementasi mesin browser, dan kekayaan API rendering-nya, tidak boleh menjadi faktor pembatas UX di web.
Anda tidak perlu mengkhawatirkan bug browser yang membuat fitur tidak dapat diandalkan, atau merusak rendering situs Anda.
Tidak boleh ada tebing performa yang misterius. Selain itu, Anda tidak perlu mengatasi fitur bawaan yang hilang.
Seharusnya fitur tersebut dapat berfungsi.
RenderingNG adalah langkah besar untuk mencapai sasaran bintang utara ini. Sebelum RenderingNG, kami dapat (dan memang) menambahkan fitur rendering dan meningkatkan performa, tetapi kami kesulitan membuat fitur tersebut dapat diandalkan bagi developer, dan terdapat banyak terobosan performa. Sekarang kita memiliki arsitektur yang secara sistematis mengatasi banyak masalah tersebut, dan juga membuka blokir fitur lanjutan yang sebelumnya tidak dianggap layak. Persyaratan ini:
- Memiliki fitur inti yang solid di berbagai kombinasi platform, perangkat, dan sistem operasi.
- Memiliki performa yang dapat diprediksi dan andal.
- Memaksimalkan penggunaan kemampuan hardware (inti, GPU, resolusi layar, kecepatan refresh, API raster tingkat rendah).
- Hanya melakukan pekerjaan yang diperlukan untuk menampilkan konten yang dapat dilihat.
- Memiliki dukungan bawaan untuk desain visual, animasi, dan pola desain interaksi yang umum.
- Menyediakan API developer untuk mengelola biaya rendering dengan mudah.
- Menyediakan titik ekstensi pipeline rendering untuk add-in developer.
- Mengoptimalkan semua konten—HTML, CSS, 2D Canvas, kanvas 3D, gambar, video, dan font.
Perbandingan dengan mesin rendering browser lainnya
Gecko dan Webkit juga telah menerapkan sebagian besar fitur arsitektur yang sama seperti yang dijelaskan dalam postingan blog ini, dan dalam beberapa kasus bahkan menambahkan fitur tersebut sebelum Chromium.
Setiap browser yang menjadi lebih cepat dan lebih andal harus dirayakan dan berdampak nyata. Sasaran akhirnya adalah meningkatkan dasar pengukuran untuk semua browser, sehingga developer dapat mengandalkannya.
Piramida kesuksesan
Filosofi saya adalah kesuksesan adalah hasil dari pencapaian keandalan, kemudian performa skalabel, dan terakhir ekstensibilitas.
Seperti halnya piramida di dunia nyata, setiap tingkat memberikan fondasi yang pasti kuat untuk tingkat di atas.
Keandalan
Jika pengalaman pengguna yang kaya dan kompleks dapat diwujudkan, hal pertama yang kita perlukan adalah platform yang kokoh. Fitur inti dan landasan harus berfungsi dengan benar, dan tetap berfungsi seiring waktu. Dan tidak kalah penting, fitur-fitur tersebut tersusun dengan baik dan tidak memiliki perilaku kasus ekstrem atau bug yang aneh.
Karena alasan ini, keandalan adalah satu-satunya bagian terpenting dari RenderingNG. Keandalan adalah hasil dari pengujian yang baik, feedback loop yang berkualitas, metrik, dan pola desain software.
Untuk memberikan gambaran betapa pentingnya keandalan, kami menghabiskan sebagian besar delapan tahun terakhir untuk menyelesaikan bagian ini. Pertama, kami membangun pengetahuan mendalam tentang sistem—belajar dari laporan bug titik kelemahan dan memperbaikinya, melakukan pengujian yang komprehensif, serta memahami kebutuhan performa situs dan batasan performa Chromium. Kemudian, kami merancang serta meluncurkan pola desain dan struktur data yang penting dan bertahap. Barulah saat itu kami siap menambahkan primitif generasi berikutnya yang benar-benar untuk desain responsif, skalabilitas, dan penyesuaian rendering.
Namun, bukan berarti tidak ada fitur yang ditingkatkan selama periode tersebut di Chromium. Bahkan, kebalikannya benar. Tahun-tahun tersebut mengalami peningkatan keandalan dan performa yang stabil dan berkelanjutan saat kami melakukan pemfaktoran ulang dan meluncurkan setiap peningkatan langkah demi langkah.
Pengujian dan metrik
Selama 8 tahun terakhir, kami telah menambahkan puluhan ribu pengujian unit, performa, dan integrasi. Selain itu, kami telah mengembangkan metrik komprehensif yang mengukur banyak aspek perilaku rendering Chromium dalam pengujian lokal, dalam tolok ukur performa, dan dalam hal lain di situs sungguhan, dengan pengguna dan perangkat sungguhan.
Namun, tidak peduli seberapa hebat RenderingNG (atau dalam hal ini mesin rendering browser lain), mengembangkan untuk web tidak akan mudah jika ada banyak bug atau perbedaan perilaku antar-browser. Untuk mengatasi hal ini, kami juga memaksimalkan penggunaan Pengujian Platform Web. Setiap pengujian ini memverifikasi pola penggunaan platform web yang harus dilalui oleh semua browser. Kami juga memantau metrik dengan cermat agar lulus lebih banyak pengujian dari waktu ke waktu dan meningkatkan kompatibilitas inti.
Pengujian Platform Web adalah upaya kolaboratif. Misalnya, engineer Chromium hanya menambahkan sekitar 10% dari total pengujian WPT untuk fitur CSS; vendor browser lainnya, kontributor independen, dan penulis spesifikasi berkontribusi sisanya. Butuh satu desa untuk membangun web yang dapat dioperasikan bersama!
Pola desain perangkat lunak yang baik
Oleh karena itu, mengirimkan software berkualitas dengan andal akan jauh lebih mudah jika kodenya mudah dipahami, dan dirancang dengan cara yang meminimalkan kemungkinan bug. Kami akan membahas lebih banyak hal tentang desain software RenderingNG di postingan blog berikutnya.
Performa yang skalabel
Mencapai performa yang luar biasa—di seluruh dimensi kecepatan, memori, dan penggunaan daya—adalah aspek terpenting berikutnya dari RenderingNG. Kita ingin interaksi dengan semua situs web berjalan lancar dan responsif, tetapi tidak mengorbankan stabilitas perangkat.
Namun, kita tidak hanya menginginkan performa, kami juga ingin performa yang skalabel, yakni arsitektur yang berperforma baik dan andal pada komputer kelas bawah dan kelas atas, serta di berbagai platform OS. Saya menyebutnya peningkatan skala—memanfaatkan semua yang dapat dicapai perangkat hardware, dan memperkecil skala—memaksimalkan efisiensi dan mengurangi permintaan pada sistem saat diperlukan.
Untuk mencapainya, kami perlu memaksimalkan penggunaan caching, isolasi performa, dan akselerasi hardware GPU. Mari kita pertimbangkan masing-masingnya secara bergantian. Agar lebih konkret, mari kita pikirkan bagaimana masing-masing fitur berkontribusi pada performa dari satu interaksi yang sangat penting di halaman web: scrolling.
Menyimpan ke cache
Dalam platform UI interaktif yang dinamis seperti web, cache adalah satu-satunya cara terpenting untuk meningkatkan performa secara drastis. Jenis caching yang paling terkenal di browser adalah cache HTTP, tetapi rendering juga memiliki banyak cache. Cache terpenting untuk scroll adalah tekstur GPU yang di-cache dan daftar tampilan, yang memungkinkan scroll menjadi sangat cepat sekaligus meminimalkan konsumsi baterai dan berfungsi dengan baik di berbagai perangkat.
Menyimpan ke cache membantu masa pakai baterai dan kecepatan frame animasi untuk scroll, tetapi yang lebih penting adalah membuka blokir isolasi performa dari thread utama.
Isolasi performa
Pada komputer desktop modern, Anda tidak perlu khawatir tentang aplikasi latar belakang yang memperlambat pekerjaan Anda. Hal ini terjadi karena multitasking preemtif, yang merupakan bentuk isolasi performa: memastikan tugas independen tidak memperlambat satu sama lain.
Di web, contoh terbaik dari isolasi performa adalah men-scroll. Bahkan di situs yang memiliki banyak JavaScript lambat, scroll dapat menjadi sangat lancar, karena berjalan di thread berbeda yang tidak harus bergantung pada JavaScript dan thread tata letak. Kami telah berupaya keras dalam RenderingNG untuk memastikan bahwa setiap kemungkinan scroll telah di-thread, melalui caching yang lebih dari sekadar daftar tampilan untuk situasi yang lebih kompleks. Contohnya mencakup kode untuk merepresentasikan elemen yang diposisikan secara tetap dan melekat, pemroses peristiwa pasif, dan rendering teks berkualitas tinggi.
Akselerasi GPU
GPU membuat pembuatan piksel dan gambar ke layar jauh lebih cepat—dalam banyak kasus, setiap piksel dapat digambar secara paralel dengan setiap piksel lainnya, sehingga mengakibatkan peningkatan kecepatan yang sangat besar. Komponen utama RenderingNG adalah raster GPU dan menggambar di mana saja. Hal ini menggunakan GPU pada semua platform, dan semua perangkat, untuk mempercepat rendering dan animasi konten web. Hal ini terutama penting pada perangkat kelas bawah atau perangkat kelas atas, yang sering kali memiliki GPU yang jauh lebih mampu daripada bagian perangkat lainnya.
Ekstensibilitas: Alat yang tepat untuk pekerjaan
Setelah kami memiliki keandalan dan performa yang skalabel, kami sekarang siap untuk membuat di atas berbagai alat untuk membantu developer memperluas bagian bawaan HTML, CSS, dan Canvas, dan dengan cara yang tidak mengorbankan performa dan keandalan yang sudah diraih dengan susah payah.
Hal ini mencakup API bawaan dengan eksposur JavaScript untuk kasus penggunaan lanjutan desain responsif, rendering progresif, kelancaran dan responsivitas, serta rendering thread.
API web terbuka berikut, yang didukung oleh Chromium, dimungkinkan oleh RenderingNG, dan sebelumnya dianggap tidak memungkinkan.
Semuanya dikembangkan dengan spesifikasi terbuka dan kolaborasi dengan partner web terbuka—insinyur di browser, pakar, dan developer web lain. Dalam postingan blog berikutnya, kami akan membahasnya masing-masing dan menjelaskan bagaimana RenderingNG memungkinkannya.
- visibilitas konten: memungkinkan situs dengan mudah menghindari pekerjaan rendering untuk konten di luar layar, dan rendering cache untuk tampilan aplikasi satu halaman yang saat ini tidak ditampilkan.
- OffscreenCanvas: memungkinkan rendering kanvas (baik Canvas 2D API maupun WebGL) berjalan pada threadnya sendiri untuk performa yang sangat baik dan andal. Project ini juga merupakan tonggak pencapaian besar lainnya bagi web—ini adalah API web pertama yang memungkinkan JavaScript (atau WebAssembly) untuk merender satu dokumen halaman web dari beberapa thread.
- Kueri container: memungkinkan satu komponen untuk menata letaknya secara responsif, membuka blokir seluruh komponen plug-and-play (saat ini masih dalam tahap implementasi eksperimental).
- Isolasi asal: memungkinkan situs memilih untuk lebih mengisolasi performa di antara iframe.
- Worklet cat di luar thread: memberi developer cara untuk memperluas cara elemen digambar, dengan kode yang berjalan di thread compositor.
Selain API web eksplisit, RenderingNG memungkinkan kami mengirimkan beberapa "fitur otomatis" yang sangat signifikan yang menguntungkan semua situs:
- Isolasi Situs: menempatkan iframe lintas origin dalam proses CPU yang berbeda untuk memberikan isolasi performa dan keamanan yang lebih baik.
- Vulkan, D3D12, dan Metal: memanfaatkan API dengan level lebih rendah yang menggunakan GPU secara lebih efisien daripada OpenGL.
- Animasi gabungan lainnya: SVG, warna latar belakang.
Fitur tambahan mendatang yang dibuka blokirnya oleh RenderingNG yang sangat kami sukai meliputi:
- Animasi tertaut scroll.
- DOM yang disembunyikan, namun dapat ditelusuri dan diakses.
- Transisi elemen bersama.
- Tata letak kustom.
- Komposisi thread utama; memisahkan threading dan pengomposisian.
Project utama yang membentuk RenderingNG
Berikut adalah daftar project utama dalam RenderingNG.
CompositeAfterPaint
CompositeAfterPaint memisahkan komposisi dari gaya, tata letak, dan paint, sehingga memungkinkan keandalan yang jauh lebih baik dan performa yang dapat diprediksi, peningkatan throughput, serta penggunaan lebih sedikit memori tanpa mengorbankan performa.
| Tahun | Progres |
|---|---|
| 2015 | Kirimkan daftar tampilan. |
| 2017 | Kirimkan pembatalan validasi baru. |
| 2018 | Pohon properti kapal bagian 1. |
| 2019 | Pohon properti kapal bagian 2. |
| 2021 | Menyelesaikan pengiriman project. |
LayoutNG
Penulisan ulang dari awal semua algoritma tata letak, untuk keandalan yang lebih baik dan performa yang lebih dapat diprediksi.
Baca selengkapnya tentang LayoutNG.
| Tahun | Progres |
|---|---|
| 2019 | Alur blok pengiriman. |
| 2020 | Kirim dengan fleksibel, sedang mengedit. |
| 2021 | Kirimkan yang lainnya. |
BlinkNG
Kami telah memfaktorkan ulang dan membersihkan Blink rendering engine ke dalam fase pipeline yang dipisahkan dengan rapi. Hal ini memungkinkan caching yang lebih baik, keandalan yang lebih tinggi, dan fitur re-entran atau rendering tertunda seperti visibilitas konten dan kueri penampung.
Akselerasi GPU di mana saja
Akselerasi GPU memberikan percepatan yang luar biasa untuk sebagian besar konten, karena setiap piksel dapat diproses secara paralel. Metode ini juga merupakan metode efektif untuk meningkatkan performa pada perangkat kelas bawah, yang cenderung masih memiliki GPU.
| Tahun | Progres |
|---|---|
| 2014 | Dukungan Canvas. Dikirim pada konten keikutsertaan di Android. |
| 2016 | Dikirim di Mac. |
| 2017 | GPU digunakan pada lebih dari 60% tayangan halaman Android. |
| 2018 | Dikirimkan di Windows, ChromeOS, dan Android Go. |
| 2019 | Threaded GPU rasterisasi. |
| 2020 | Mengirimkan konten Android lainnya. |
Scroll dengan untaian, animasi, dan dekode
Upaya jangka panjang untuk memindahkan semua scroll, animasi yang tidak memicu tata letak, dan decoding gambar dari thread utama. Ini sedang berlangsung.
| Tahun | Progres |
|---|---|
| 2011 | Dukungan awal untuk scroll dan animasi dengan untaian. |
| 2015 | {i>Layer squashing<i}. |
| 2016 | Scroll luapan universal. |
| 2017 | Dekode gambar pada thread compositor. |
| 2018 | Animasi Gambar di thread compositor. |
| 2020 | Selalu komposit posisi tetap. |
| 2021 | Animasi transformasi persentase, animasi SVG. |
Viz
Proses menggambar dan raster terpusat untuk Chromium yang meningkatkan throughput, mengoptimalkan memori, dan memungkinkan penggunaan kemampuan hardware secara optimal. Fitur ini memiliki manfaat lain yang kurang terlihat oleh developer web, tetapi sangat terlihat oleh pengguna, seperti berhenti memblokir Isolasi Situs dan memisahkan pipeline rendering dari rendering UI browser.
| Tahun | Progres |
|---|---|
| 2018 | OOP-R diluncurkan di Android, Mac, dan Windows. |
| 2019 | OOP-D terkirim. OOP-R dikirim ke mana saja (kecuali Canvas). SkiaRenderer dikirimkan di Linux. |
| 2020 | SkiaRenderer dikirimkan di Windows & Android. Vulkan diluncurkan di Android. |
| 2021 | SkiaRenderer dikirimkan di Mac (dan segera ChromeOS). |
Definisi istilah dalam diagram di atas:
- OOP-D
- Kopositor tampilan di luar proses. Pengomposisian tampilan adalah jenis aktivitas yang sama dengan kompositor OS. Di luar proses berarti melakukannya dalam proses Viz, bukan proses render halaman web atau proses UI browser.
- OOP-R
- Raster di luar proses. Raster mengonversi daftar tampilan menjadi piksel. Di luar proses berarti melakukannya dalam proses Viz, bukan proses render halaman web.
- SkiaRenderer
- Implementasi compositor display baru yang dapat mendukung eksekusi pada berbagai API GPU dasar yang berbeda seperti Vulkan, D3D12, atau Metal.
Rendering kanvas dengan utas dan dipercepat
Inilah proyek yang memungkinkan OffscreenCanvas.
| Tahun | Progres |
|---|---|
| 2018 | Kirim Kanvas Luar Layar. |
| 2019 | Mengirim ImageBitmapRenderingContext. |
| 2021 | Kirim OOP-R. |
VideoNG
VideoNG adalah upaya jangka panjang untuk menyediakan pemutaran video yang efisien, andal, dan berkualitas tinggi di web.
| Tahun | Progres |
|---|---|
| 2014 | Memperkenalkan framework rendering berbasis Mojo. |
| 2015 | Pengiriman Project Butter dan overlay video untuk rendering video yang lebih lancar. |
| 2016 | Menghadirkan pipeline decoding dan rendering Android dan desktop terpadu. |
| 2017 | HDR yang dikirimkan dan rendering video yang dikoreksi warna. |
| 2018 | Pipeline dekode video berbasis Mojo yang telah dikirim. |
| 2019 | Pipeline rendering video berbasis Permukaan yang dikirim. |
| 2021 | Mengirimkan dukungan rendering konten yang dilindungi 4K di ChromeOS. |
Definisi istilah dalam diagram di atas:
- Mojo
- Subsistem IPC generasi berikutnya untuk Chromium.
- Platform
- Konsep yang merupakan bagian dari desain project Viz.
Ilustrasi oleh Una Kravets.