RenderingNG

Siap untuk konten web generasi berikutnya

Chris Harrelson
Chris Harrelson

Saya Chris Harrelson, {i>engineer lead<i} untuk {i>Rendering <i} (mengubah HTML dan CSS menjadi piksel) di Blink. Saya mempelajari performa rendering di web selama lebih dari delapan tahun, dengan tujuan pribadi melakukan apa pun semampu saya untuk membuat UX yang luar biasa di web menjadi lebih cepat, lebih mudah, dan lebih andal. Dengan senang hati kami akan memberi tahu Anda tentang hal-hal yang telah kami lakukan pada saat itu untuk membangun arsitektur mesin rendering Chromium yang baru dan canggih. Untuk mencapai hal ini adalah pekerjaan yang luar biasa besar disertai cinta, dan saya harap Anda senang mendengarnya!

Pada tahun 2021, kita akan menyelesaikan sebagian besar proses perancangan, pembangunan, dan pengiriman arsitektur ini. Sebut saja RenderingNG, karena ini benar-benar arsitektur rendering generasi berikutnya yang sangat mengungguli versi sebelumnya. RenderingNG telah berlangsung setidaknya selama delapan tahun, dan mewakili pekerjaan kolektif dari banyak developer Chromium khusus. Hal ini membuka banyak potensi bagi konten web generasi berikutnya yang cepat, lancar, andal, responsif, dan interaktif. Ini juga merupakan dasar yang saya yakini menentukan standar minimum baru untuk semua mesin rendering web yang dapat diandalkan oleh developer.

Sketsa berbagai elemen RenderingNG
RenderingNG

Postingan blog ini adalah yang pertama dari rangkaian, di mana kami akan menjelaskan apa yang kami buat, mengapa kami membuatnya, dan cara kerjanya. Dalam postingan pertama ini, saya akan mulai dengan:

  • Sasaran utama kita.
  • Piramida kesuksesan: prinsip-prinsip yang memandu pekerjaan kita, dan contoh dalam praktiknya.
  • Fitur dan kemampuan yang dimungkinkan oleh RenderingNG.
  • Ringkasan tingkat tinggi komponen project utama RenderingNG.

Bintang utara

Sasaran utama yang memotivasi RenderingNG adalah bahwa penerapan mesin browser, dan kekayaan API renderingnya, tidak boleh menjadi faktor pembatas UX di web.

Anda tidak perlu khawatir dengan bug browser yang menjadikan fitur tidak dapat diandalkan, atau merusak rendering situs.

Tidak boleh ada tebing pertunjukan yang misterius. Selain itu, Anda tidak perlu mengatasi masalah fitur bawaan yang hilang.

Seharusnya perangkat akan berfungsi dengan baik.

Saya yakin RenderingNG adalah langkah besar untuk mencapai sasaran bintang utara ini. Sebelum RenderingNG, kami dapat (dan melakukannya) menambahkan fitur rendering dan meningkatkan performa, tetapi kami kesulitan membuat fitur tersebut andal bagi developer, dan ada banyak perbedaan performa. Sekarang kita memiliki arsitektur yang secara sistematis mengatasi banyak masalah tersebut, dan juga membuka fitur lanjutan yang sebelumnya dianggap tidak layak. Persyaratan ini:

  • Memiliki fitur inti yang sangat kuat di berbagai kombo 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 terlihat.
  • 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, Kanvas 2D, 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 menambahkannya sebelum Chromium. Dan itu bagus sekali. Meskipun browser yang menjadi lebih cepat dan lebih andal merupakan alasan untuk dirayakan dan memiliki dampak yang nyata, sasaran utamanya adalah untuk meningkatkan dasar pengukuran untuk semua browser, sehingga developer dapat mengandalkannya.

Piramida kesuksesan

Filosofi saya adalah bahwa kesuksesan adalah hasil dari pertama kali mencapai keandalan, kemudian performa yang skalabel, dan terakhir, ekstensibilitas.

Piramida dengan label Keandalan di bagian dasar,
Performa di tengah, ekstensibilitas di bagian atas

Seperti halnya piramida di dunia nyata, setiap level memberikan fondasi yang kuat untuk level di atasnya.

Keandalan

Sketsa yang menunjukkan cara dengan fitur RenderingNG dapat ditambahkan tanpa menimbulkan kesulitan yang besar

Jika pengalaman pengguna yang kaya dan kompleks dapat diwujudkan, hal pertama yang kami perlukan adalah platform yang dapat diandalkan. Fitur inti dan dasar-dasarnya harus berfungsi dengan benar, dan terus berfungsi dari waktu ke waktu. Selain itu, fitur-fitur tersebut dapat disusun dengan baik dan tidak memiliki perilaku kasus ekstrem atau bug yang aneh.

Sketsa menunjukkan sifat alamiah dalam menambahkan fitur, mendapatkan masukan, meningkatkan keandalan

Karena alasan ini, keandalan adalah satu-satunya bagian terpenting dari RenderingNG. Dan keandalan adalah hasil dari pengujian yang baik, feedback loop, metrik, dan pola desain software yang berkualitas.

Untuk lebih memahami pentingnya keandalan, kami menghabiskan sebagian besar delapan tahun terakhir hanya untuk membahas bagian ini. Pertama, kami membangun pengetahuan mendalam tentang sistem—belajar dari laporan bug yang memiliki titik lemah dan memperbaikinya, melakukan bootstrap pengujian komprehensif, dan memahami kebutuhan performa situs dan batasan performa Chromium. Kemudian kami dengan hati-hati dan secara bertahap merancang dan meluncurkan pola desain utama dan struktur data. Baru setelah itu, kami siap untuk menambahkan primitif generasi berikutnya yang benar-benar baru untuk desain responsif, skalabilitas, dan penyesuaian rendering.

Grafik sketsa menunjukkan keandalan, performa, dan ekstensibilitas yang meningkat seiring waktu

Hal ini bukan berarti bahwa tidak ada yang ditingkatkan selama waktu tersebut di Chromium. Bahkan, berlaku sebaliknya. Pada tahun-tahun tersebut, keandalan dan performa mengalami peningkatan yang stabil dan berkelanjutan seiring kami memfaktorkan 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 tentang perilaku rendering Chromium dalam pengujian lokal, dalam tolok ukur performa, dan di luar situs nyata, dengan pengguna dan perangkat sungguhan.

Namun, tidak peduli seberapa hebat RenderingNG (atau dalam hal ini mesin rendering browser lain), pengembangan untuk web tetap tidak akan mudah jika terdapat 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 semua browser. Kami juga memantau dengan cermat metrik untuk lulus lebih banyak pengujian dari waktu ke waktu dan meningkatkan kompatibilitas inti.

Pengujian Platform Web merupakan upaya kolaboratif. Misalnya, engineer Chromium hanya menambahkan sekitar 10% dari total pengujian WPT untuk fitur CSS; sisanya adalah vendor browser, kontributor independen, dan penulis spesifikasi lainnya, yang berkontribusi. Perlu desa untuk mengembangkan web yang memiliki interoperabilitas!

Pengujian yang lulus di mesin yang berbeda
Dari wpt.fyi/compat2021, mengukur rasio kelulusan WPT untuk fitur inti

Pola desain software yang baik

Mengirimkan software berkualitas dengan andal akan jauh lebih mudah jika kodenya mudah dipahami, dan dirancang sedemikian rupa untuk meminimalkan kemungkinan bug. Kami akan membahas lebih banyak tentang desain software RenderingNG dalam postingan blog berikutnya.

Performa yang skalabel

Mencapai performa luar biasa di seluruh dimensi kecepatan, memori, dan penggunaan daya, adalah aspek terpenting berikutnya dari RenderingNG. Kita ingin interaksi dengan semua situs web berjalan mulus dan responsif, namun tidak mengorbankan stabilitas perangkat.

Namun, kita tidak hanya menginginkan performa, melainkan juga performa yang dapat diskalakan—arsitektur yang berperforma sangat baik pada komputer low-end dan high-end, serta di berbagai platform OS. Saya menyebutnya peningkatan skala—memanfaatkan semua yang dapat dicapai perangkat hardware, dan menurunkan skala—memaksimalkan efisiensi serta mengurangi permintaan pada sistem saat dibutuhkan.

Untuk mencapainya, kami perlu memanfaatkan penyimpanan cache secara maksimal, isolasi performa, dan akselerasi hardware GPU. Mari kita pelajari satu per satu. Untuk membuatnya konkret, mari kita pikirkan bagaimana masing-masing peran tersebut berkontribusi pada kinerja satu interaksi yang sangat penting di laman web: menggulir.

Menyimpan ke cache

Dalam platform UI yang dinamis dan interaktif seperti web, cache adalah satu-satunya cara terpenting untuk meningkatkan performa secara signifikan. Jenis cache yang paling terkenal di browser adalah cache HTTP, namun 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.

Caching membantu masa pakai baterai dan kecepatan frame animasi untuk men-scroll, tetapi yang lebih penting adalah membuka pemblokiran performa dari thread utama.

Isolasi performa

Pada komputer desktop modern, Anda tidak perlu khawatir tentang aplikasi latar belakang yang memperlambat aplikasi yang sedang Anda kerjakan. Hal ini dikarenakan multitasking preemtif, yang kemudian menjadi bentuk isolasi performa: memastikan tugas independen tidak memperlambat satu sama lain.

Di web, contoh terbaik dari isolasi performa adalah scroll. Bahkan pada situs yang memiliki banyak JavaScript lambat, scroll bisa berjalan sangat lancar, karena berjalan pada thread berbeda yang tidak harus bergantung pada JavaScript dan thread tata letak. Kami berupaya keras dalam RenderingNG untuk memastikan bahwa setiap scroll yang memungkinkan di-thread, melalui caching yang tidak hanya menampilkan daftar tampilan, tetapi juga dapat digunakan pada situasi yang lebih kompleks. Contohnya mencakup kode untuk merepresentasikan elemen yang diposisikan tetap dan melekat, pemroses peristiwa pasif, dan rendering teks berkualitas tinggi.

Sketsa menunjukkan bahwa dengan performa RenderingNG tetap solid bahkan saat JavaScript sangat lambat.

Akselerasi GPU

GPU membuat pembuatan piksel dan penggambaran ke layar menjadi jauh lebih cepat—dalam banyak kasus, setiap piksel dapat digambar secara paralel dengan setiap piksel lainnya, sehingga menghasilkan peningkatan kecepatan yang sangat besar. Komponen utama RenderingNG adalah raster GPU dan menggambar di mana saja. Sistem ini menggunakan GPU pada semua platform, dan semua perangkat, untuk mempercepat rendering dan animasi konten web. Hal ini sangat penting pada perangkat kelas bawah atau perangkat sangat kelas atas, yang sering kali memiliki GPU yang jauh lebih mumpuni daripada bagian lain dari perangkat.

Sketsa menunjukkan bahwa dengan performa RenderingNG tidak banyak menurun.

Ekstensibilitas: Alat yang tepat untuk pekerjaan

Setelah memiliki keandalan dan performa skalabel, kami kini siap untuk membangun di atas serangkaian alat untuk membantu developer mengembangkan bagian bawaan HTML, CSS, dan Canvas, dan dengan cara yang tidak mengorbankan kinerja dan keandalan apa pun yang sudah diupayakan dengan susah payah.

Hal ini mencakup API bawaan plus yang terekspos JavaScript untuk kasus penggunaan lanjutan desain responsif, rendering progresif, kelancaran dan responsivitas, serta rendering berangkai.

API web terbuka berikut, yang dijuluki oleh Chromium, dimungkinkan oleh RenderingNG, dan sebelumnya dianggap tidak mungkin.

Semuanya dikembangkan dengan spesifikasi terbuka dan kolaborasi dengan partner web terbuka—engineer di browser, pakar, dan developer web lain. Dalam entri blog berikutnya, kami akan mendalami tiap-tiapnya dan menjelaskan bagaimana RenderingNG memungkinkannya.

  • content-visibilitas: memungkinkan situs menghindari pekerjaan rendering untuk konten di luar layar, dan rendering cache untuk penayangan aplikasi halaman tunggal yang saat ini tidak ditampilkan dengan mudah.
  • OffscreenCanvas: memungkinkan rendering kanvas (baik API kanvas 2D maupun WebGL) berjalan di threadnya sendiri untuk menghasilkan performa yang sangat baik dan dapat diandalkan. Project ini juga menjadi pencapaian besar lainnya bagi web. Project ini merupakan API web pertama yang memungkinkan JavaScript (atau WebAssembly) merender satu dokumen halaman web dari beberapa thread.
  • Kueri container: memungkinkan satu komponen untuk menata letaknya secara responsif, sehingga tidak memblokir seluruh komponen plug-and-play (saat ini merupakan implementasi eksperimental).
  • Isolasi origin: memungkinkan situs memilih untuk menerapkan isolasi performa yang lebih ketat di antara iframe.
  • Worklet paint di luar thread utama: memberi developer cara untuk memperluas cara menggambar elemen, dengan kode yang berjalan pada thread compositor.

Selain API web eksplisit, RenderingNG memungkinkan kami mengirimkan beberapa "fitur otomatis" yang sangat signifikan yang bermanfaat bagi semua situs:

  • Isolasi Situs: menempatkan iframe lintas origin dalam proses CPU yang berbeda, untuk isolasi performa dan keamanan yang lebih baik.
  • Vulkan, D3D12, dan Metal: memanfaatkan API dengan tingkat lebih rendah yang menggunakan GPU lebih efisien daripada OpenGL.
  • Animasi yang lebih gabungan: SVG, warna latar belakang.

Fitur mendatang lainnya yang tidak diblokir oleh RenderingNG, yang kami sukai, meliputi:

Project utama yang membentuk RenderingNG

Di bawah ini adalah daftar project utama dalam RenderingNG. Postingan blog berikutnya akan membahasnya masing-masing secara mendalam.

CompositeAfterPaint

Mengomposisikan komposisi dari gaya, tata letak, dan cat, memungkinkan keandalan dan performa yang dapat diprediksi yang jauh lebih baik, peningkatan throughput, dan penggunaan lebih sedikit memori tanpa mengorbankan performa. Program ini dimulai tahun 2014 dan akan selesai tahun ini.

Tahun Progres
2015 Mengirimkan daftar tampilan.
2017 Kirimkan pembatalan validasi baru.
2018 Pohon properti pengiriman bagian 1.
2019 Pohon properti pengiriman bagian 2.
2021 Menyelesaikan pengiriman proyek.

LayoutNG

Penulisan ulang semua algoritma tata letak dari awal, untuk keandalan yang jauh lebih baik dan performa yang lebih dapat diprediksi. Program ini dimulai tahun 2016 dan direncanakan selesai tahun ini.

Tahun Progres
2019 Alur blok pengiriman.
2020 Kirimkan fleksibilitas, pengeditan.
2021 Kirimkan lainnya.

BlinkNG

Pembersihan dan pemfaktoran ulang mesin rendering Blink yang sistematis ke dalam beberapa fase pipeline yang dipisahkan secara rapi. Hal ini memungkinkan penyimpanan cache yang lebih baik, keandalan yang lebih tinggi, dan fitur rendering ulang atau rendering tertunda seperti visibilitas konten dan kueri penampung. Program ini dimulai pada tahun 2014, dan mengalami peningkatan bertahap dan telah berlangsung sejak saat itu. Proses ini akan selesai pada tahun 2021.

Akselerasi GPU di mana saja

Upaya jangka panjang untuk meluncurkan rasterisasi, gambar, dan animasi GPU di semua platform, setiap saat. Akselerasi GPU memberikan percepatan yang sangat besar untuk sebagian besar konten, karena setiap piksel dapat diproses secara paralel. Ini juga merupakan metode yang efektif untuk meningkatkan kinerja pada perangkat kelas bawah, yang cenderung masih memiliki GPU. Dimulai tahun 2014 dan selesai tahun 2020.

Tahun Progres
2014 Dukungan Canvas. Dikirim saat konten keikutsertaan di Android.
2016 Mengirim di Mac.
2017 GPU digunakan pada lebih dari 60% kunjungan halaman Android.
2018 Tersedia di Windows, ChromeOS, dan Android Go.
2019 Untaian rasterisasi GPU.
2020 Mengirim konten Android yang tersisa.

Scroll dengan thread, animasi, dan dekode

Upaya jangka panjang untuk memindahkan semua animasi scroll yang tidak menyebabkan tata letak, dan decoding gambar dari thread utama. Program ini dimulai pada tahun 2011 dan masih berjalan.

Tahun Progres
2011 Dukungan awal untuk scroll dan animasi berangkai.
2015 Pemampatan lapisan.
2016 Scroll luapan universal.
2017 Dekode gambar pada thread compositor.
2018 Animasi Gambar di thread compositor.
2020 Selalu gabungan posisi tetap.
2021 Animasi transformasi persentase, animasi SVG.

{i>Viz<i}

Proses gambar dan raster terpusat untuk Chromium yang meningkatkan throughput, mengoptimalkan memori, dan memungkinkan penggunaan kemampuan hardware yang optimal. Fitur ini juga 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. Proyek ini dimulai tahun 2016 dan akan selesai pada tahun 2021.

Tahun Progres
2018 OOP-R tersedia di Android, Mac, dan Windows.
2019 OOP-D dikirimkan. OOP-R telah 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 ChromeOS segera).

Definisi istilah dalam diagram di atas:

OP-D
Compositor 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 mengubah daftar tampilan menjadi piksel. Di luar proses berarti melakukannya dalam proses Viz, bukan proses render halaman web.
SkiaRenderer
Implementasi compositor tampilan baru yang dapat mendukung eksekusi pada berbagai API GPU dasar seperti Vulkan, D3D12, atau Metal.

Rendering kanvas dengan thread dan percepatan

Ini adalah project yang menempatkan bagian arsitektur yang memungkinkan OffscreenCanvas. Dimulai tahun 2015 dan akan selesai pada tahun 2021.

Tahun Progres
2018 Mengirimkan OffscreenCanvas.
2019 Mengirimkan ImageBitmapRenderingContext.
2021 Mengirim OOP-R.

VideoNG

Upaya jangka panjang untuk menyediakan pemutaran video yang efisien, andal, dan berkualitas tinggi di web.

Tahun Progres
2014 Memperkenalkan framework rendering berbasis Mojo.
2015 Mengirimkan Project Butter dan overlay video untuk rendering video yang lebih lancar.
2016 Mengirimkan pipeline rendering dan decoding Android dan desktop terpadu yang dikirimkan.
2017 Mengirim rendering video HDR dan video yang dikoreksi warna.
2018 Pipeline dekode video berbasis Mojo yang dikirimkan.
2019 Pipeline rendering video berbasis Platform yang dikirimkan.
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.

Kesimpulan

Saya sangat antusias dengan kecepatan peningkatan rendering di web dan Chromium. Saya memperkirakan laju langkah ini akan terus dipercepat dalam beberapa tahun mendatang karena kami dapat membangun di atas dasar yang kuat dari RenderingNG.

Nantikan postingan mendatang lainnya yang akan membahas lebih detail tentang arsitektur baru, bagaimana kondisinya, dan cara kerjanya.

Foto perangkat oleh Eirik Solheim di Unsplash

Ilustrasi oleh Una Kravets.