Pronto per la prossima generazione di contenuti web
RenderingNG è un'architettura di rendering di nuova generazione che offre prestazioni superiori a quelle precedenti. RenderingNG è stato realizzato in più di otto anni e rappresenta il lavoro collettivo di molti sviluppatori. Offre un'enorme quantità di potenziale per contenuti web veloci, fluidi, affidabili, reattivi e interattivi.
Qui scoprirai cosa abbiamo creato, perché e come funziona.
Obiettivo North Star
L'obiettivo principale che motiva RenderingNG è che l'implementazione del motore del browser e la ricchezza delle sue API di rendering non dovrebbero essere un fattore limitante dell'UX sul web.
Non devi preoccuparti di eventuali bug del browser che rendono inaffidabili le funzionalità o danneggiano il rendering del sito.
Non dovrebbero esserci misteriosi scarti prestazioni. Inoltre, non dovrebbe essere necessario aggirare le funzionalità integrate mancanti.
Dovrebbe funzionare.
RenderingNG è un enorme passo avanti verso il raggiungimento di questo obiettivo della stella del nord. Prima di RenderingNG, poteva (e fatto) aggiungere funzionalità di rendering e migliorare le prestazioni, ma faticavamo a renderle affidabili per gli sviluppatori e le prestazioni erano numerose. Ora disponiamo di un'architettura che risolve sistematicamente molti di questi problemi e sblocca anche funzionalità avanzate che prima non erano ritenute fattibili. Il GDPR:
- Dispone di solide funzionalità di base su diverse combinazioni di piattaforme, dispositivi e sistemi operativi.
- Ha prestazioni prevedibili e affidabili.
- Massimizza l'utilizzo delle funzionalità hardware (core, GPU, risoluzione dello schermo, frequenze di aggiornamento, API raster di basso livello).
- Esegue solo il lavoro necessario per visualizzare contenuti visibili.
- Supporto integrato di pattern visivi, animazioni e design dell'interazione comuni.
- Offre agli sviluppatori API per gestire facilmente i costi di rendering.
- Fornisce punti di estensione della pipeline di rendering per i componenti aggiuntivi per sviluppatori.
- Ottimizza tutti i contenuti: HTML, CSS, Canvas 2D, canvas 3D, immagini, video e caratteri.
Confronto con altri motori di rendering del browser
Inoltre, Gecko e Webkit hanno implementato la maggior parte delle funzionalità architettoniche descritte in questi post del blog e, in alcuni casi, le hanno aggiunte prima di Chromium.
Qualsiasi browser che diventa più veloce e affidabile è motivo di congratulazioni e ha un impatto reale. L'obiettivo finale è far avanzare le basi per tutti i browser, in modo che gli sviluppatori possano fare affidamento su questo.
La piramide del successo
Secondo la mia filosofia, il successo è il risultato dell'ottenimento di prima affidabilità, quindi di prestazioni scalabili e infine estensibilità.
Come nel caso di una piramide reale, ogni livello fornisce una base necessariamente solida per il livello superiore.
Affidabilità
Per realizzare esperienze utente complesse e stimolanti, la prima cosa di cui abbiamo bisogno è una piattaforma solida come una roccia. Le funzionalità principali e gli elementi sottostanti devono funzionare correttamente e continuare a funzionare nel tempo. Ed è altrettanto importante che queste caratteristiche si componino bene e non presentino strani comportamenti peculiari o bug.
Per questo motivo, l'affidabilità è la parte più importante di RenderingNG. L'affidabilità è il risultato di buoni test, cicli di feedback di qualità, metriche e pattern di progettazione del software.
Per capire quanto sia importante l'affidabilità, abbiamo trascorso gran parte degli ultimi otto anni a perfezionare questa parte. Per prima cosa, abbiamo acquisito una conoscenza approfondita del sistema, imparando dalle segnalazioni di bug in cui erano presenti i punti deboli e correggendoli, eseguire test completi e comprendendo le esigenze di prestazioni dei siti e i limiti delle prestazioni di Chromium. Poi abbiamo progettato e implementato con attenzione e in modo incrementale i principali pattern di progettazione e le strutture di dati. Solo allora eravamo pronti ad aggiungere primitive davvero di nuova generazione per il responsive design, la scalabilità e la personalizzazione del rendering.
Questo non vuol dire che in questo periodo non sia stato migliorato nulla in Chromium. È vero il contrario. Quegli anni hanno visto un aumento costante e sostenuto dell'affidabilità e delle prestazioni man mano che abbiamo eseguito il refactoring e implementato ogni miglioramento passo dopo passo.
Test e metriche
Negli ultimi 8 anni abbiamo aggiunto decine di migliaia di test di unità, prestazioni e integrazione. Inoltre, abbiamo sviluppato metriche complete che misurano molti aspetti del comportamento del rendering di Chromium nei test locali, nei benchmark delle prestazioni e in natura su siti reali, con utenti e dispositivi reali.
Ma non importa quanto sia grande RenderingNG (o il motore di rendering di un altro browser, in questo caso), non sarà comunque facile svilupparlo per il web se ci sono molti bug o differenze di comportamento tra i browser. Per risolvere questo problema, massimizziamo anche l'utilizzo dei test della piattaforma web. Ciascuno di questi test verifica un modello di utilizzo della piattaforma web che tutti i browser devono cercare di superare. Monitoriamo attentamente le metriche per superare un numero maggiore di test nel tempo e aumentare la compatibilità dei core.
I test delle piattaforme web sono uno sforzo collaborativo. Ad esempio, i tecnici di Chromium hanno aggiunto solo circa il 10% dei test WPT totali per le funzionalità dei CSS; altri fornitori di browser, collaboratori indipendenti e autori delle specifiche contribuiscono al resto. Ci vuole un villaggio per far crescere il web interoperabile!
Modelli di progettazione di software efficaci
Offrire software di qualità affidabile è a sua volta molto più semplice se il codice è facile da capire e progettato in modo da ridurre al minimo la probabilità di bug. Nei prossimi post dei blog avremo molto altro da dire sulla progettazione del software di RenderingNG.
Prestazioni scalabili
Ottenere ottime prestazioni, in termini di velocità, memoria e consumo energetico, è il prossimo aspetto più importante di RenderingNG. Vogliamo che le interazioni con tutti i siti web siano fluide e reattive, senza sacrificare la stabilità del dispositivo.
Ma non vogliamo solo le prestazioni, vogliamo prestazioni scalabili, un'architettura che funziona bene in modo affidabile su macchine di fascia bassa e di fascia alta, e su piattaforme di sistemi operativi. Definisco questo approccio "scale up", sfruttando tutti i vantaggi che il dispositivo hardware può ottenere, e scale down, massimizzando l'efficienza e riducendo la domanda del sistema quando necessario.
Per raggiungere questo obiettivo, dovevamo sfruttare al massimo la memorizzazione nella cache, l'isolamento delle prestazioni e l'accelerazione hardware della GPU. Vediamoli uno alla volta. Per concretamente, pensiamo a come ciascuna di queste contribuisca alle prestazioni di un'interazione estremamente importante sulle pagine web: lo scorrimento.
Memorizzazione nella cache
In una piattaforma di UI dinamica e interattiva come il web, la memorizzazione nella cache è il modo più importante per migliorare notevolmente le prestazioni. Il tipo più noto di memorizzazione nella cache è la cache HTTP, ma anche il rendering ha molte cache. La cache più importante per lo scorrimento sono le texture GPU e gli elenchi di visualizzazione memorizzati nella cache, che consentono lo scorrimento estremamente veloce, riducendo al minimo il consumo della batteria e il corretto funzionamento su una vasta gamma di dispositivi.
La memorizzazione nella cache migliora la durata della batteria e la frequenza fotogrammi dell'animazione per lo scorrimento, ma è ancora più importante sbloccare le prestazioni dell'isolamento dal thread principale.
Isolamento delle prestazioni
Sui computer desktop moderni, non devi mai preoccuparti che le applicazioni in background rallentino quella su cui lavori. Ciò è dovuto al multitasking preventivo, che è a sua volta una forma di isolamento delle prestazioni: assicurarsi che le attività indipendenti non si rallentano a vicenda.
Sul web, l'esempio migliore di isolamento delle prestazioni è lo scorrimento. Anche sui siti web che hanno molto codice JavaScript lento, lo scorrimento può essere molto fluido, perché viene eseguito su un thread diverso che non deve dipendere da JavaScript e thread di layout. Abbiamo fatto un grande impegno in RenderingNG per assicurarci che ogni possibile scorrimento sia organizzato in thread, attraverso la memorizzazione nella cache che va ben oltre il semplice elenco di visualizzazione per situazioni più complesse. Alcuni esempi sono il codice per rappresentare gli elementi con posizionamento fisso e fisso, i listener di eventi passivi e il rendering del testo di alta qualità.
Accelerazione GPU
Una GPU rende la generazione di pixel e il disegno sullo schermo molto più veloce: in molti casi, ogni pixel può essere tracciato in parallelo con tutti gli altri pixel, con un conseguente enorme aumento della velocità. Un componente chiave di RenderingNG è il raster GPU e consente di disegnare ovunque. Viene utilizzata la GPU su tutte le piattaforme e su tutti i dispositivi per accelerare il rendering e l'animazione dei contenuti web. Ciò è particolarmente importante sui dispositivi di fascia bassa o di fascia molto alta, che spesso hanno una GPU molto più potente di altre parti del dispositivo.
Estensibilità: gli strumenti giusti per il lavoro
Una volta ottenute l'affidabilità e le prestazioni scalabili, ora è possibile creare su una serie di strumenti per aiutare gli sviluppatori a estendere le parti integrate di HTML, CSS e Canvas, in modi che non vadano a compromessi in termini di prestazioni e affidabilità.
Sono incluse le API integrate e esposte a JavaScript per casi d'uso avanzati di responsive design, rendering progressivo, fluidità e reattività e rendering in thread.
Le seguenti API web aperte, sostenute da Chromium, sono state rese possibili da RenderingNG e in precedenza erano considerate impossibili.
Tutti questi modelli sono stati sviluppati con specifiche aperte e in collaborazione con partner web aperti, ingegneri di altri browser, esperti e sviluppatori web. Nei prossimi post del blog, li analizzeremo in dettaglio e spiegheremo in che modo RenderingNG li rende possibili.
- content-visibility: consente ai siti di evitare facilmente il rendering dei contenuti fuori schermo e il rendering della cache per le visualizzazioni di applicazioni a pagina singola non attualmente mostrate.
- OffscreenCanvas: consente l'esecuzione del rendering del canvas (sia l'API Canvas 2D che WebGL) sul proprio thread per ottenere prestazioni eccellenti in modo affidabile. Questo progetto è anche un'altra importante pietra miliare per il web: è la prima API web che consente a JavaScript (o WebAssembly!) di eseguire il rendering di un singolo documento di una pagina web da più thread.
- Query container: consente la struttura reattiva di un singolo componente, sbloccando un intero universo di componenti plug-and-play (attualmente un'implementazione sperimentale).
- Isolamento dell'origine. Consente ai siti di attivare un maggiore isolamento delle prestazioni tra gli iframe.
- Worklet di colorazione fuori dal thread: offre agli sviluppatori un modo per estendere il modo in cui vengono dipinti gli elementi, con codice che viene eseguito sul thread del compositore.
Oltre alle API web esplicite, RenderingNG ci ha permesso di offrire diverse "funzionalità automatiche" molto significative che apportano vantaggi a tutti i siti:
- Isolamento dei siti: inserisci gli iframe multiorigine in diversi processi della CPU, per migliorare l'isolamento delle prestazioni e della sicurezza.
- Vulkan, D3D12 e Metal: sfruttano API di livello inferiore che utilizzano le GPU in modo più efficiente rispetto a OpenGL.
- Più animazioni composte: SVG, colore di sfondo.
Altre funzionalità in arrivo sbloccate da RenderingNG che siamo entusiasti includono:
- Animazioni con link a scorrimento.
- DOM nascosto, ma disponibile per la ricerca e accessibile.
- Transizioni di elementi condivisi.
- Layout personalizzato.
- Composizione del thread al di fuori del thread principale; disaccoppiamento di thread e composizione.
Progetti chiave che compongono RenderingNG
Ecco un elenco dei progetti chiave all'interno di RenderingNG.
CompositeAfterPaint
CompositeAfterPaint elimina i problemi di compositing da stile, layout e colorazione, consentendo un'affidabilità e prestazioni prevedibili di gran lunga migliorate, una maggiore velocità effettiva e l'utilizzo di meno memoria senza sacrificare le prestazioni.
| Anno | Avanzamento |
|---|---|
| 2015 | Elenchi di visualizzazione della spedizione. |
| 2017 | Spedire nuova annullamento convalida. |
| 2018 | Spedisci alberi proprietà (parte 1). |
| 2019 | Spedisci alberi proprietà (parte 2). |
| 2021 | È stata completata la spedizione del progetto. |
LayoutNG
Una riscrittura completa di tutti gli algoritmi di layout, per un'affidabilità notevolmente migliorata e prestazioni più prevedibili.
Ulteriori informazioni su LayoutNG.
| Anno | Avanzamento |
|---|---|
| 2019 | Flusso di blocchi navale. |
| 2020 | Nave flessibile, modifica. |
| 2021 | Spedisci tutto il resto. |
BlinkNG
Abbiamo eseguito il refactoring e ripulito il motore di rendering Blink in fasi della pipeline ben separate. Ciò consente una migliore memorizzazione nella cache, una maggiore affidabilità e funzionalità di nuovo inserimento o rendering ritardato, come la visibilità dei contenuti e le query sui container.
Accelerazione GPU ovunque
L'accelerazione GPU fornisce un'enorme velocità per la maggior parte dei contenuti, perché ogni pixel può essere elaborato in parallelo. È anche un metodo efficace per migliorare le prestazioni sui dispositivi di fascia bassa, che tendono ad avere ancora una GPU.
| Anno | Avanzamento |
|---|---|
| 2014 | Supporto di Canvas. Spedito in contenuti ad attivazione su Android. |
| 2016 | Spedisci su Mac. |
| 2017 | La GPU viene utilizzata per oltre il 60% delle visualizzazioni di pagina Android. |
| 2018 | Disponibile su Windows, ChromeOS e Android Go. |
| 2019 | Rasterizzazione GPU con thread. |
| 2020 | Spedisci contenuti Android rimanenti. |
Scorrimento in thread, animazioni e decodifica
Un'iniziativa a lungo termine per spostare dal thread principale tutte le animazioni a scorrimento, che non generano layout e la decodifica di immagini. È in corso.
| Anno | Avanzamento |
|---|---|
| 2011 | Supporto iniziale per scorrimento e animazione in thread. |
| 2015 | Compressione livello. |
| 2016 | Scorrimento extra universale. |
| 2017 | L'immagine decodifica nel thread del compositore. |
| 2018 | Animazioni immagine nel thread del compositore. |
| 2020 | Sempre composita con posizione fissa. |
| 2021 | Animazioni di trasformazione percentuale, animazioni SVG. |
Visualizzazione
Un processo centralizzato di raster e disegno per Chromium che aumenta la velocità effettiva, ottimizza la memoria e consente l'uso ottimale delle funzionalità hardware. Presenta altri vantaggi meno visibili agli sviluppatori web ma molto visibili agli utenti, come lo sblocco dell'isolamento dei siti e il disaccoppiamento della pipeline di rendering dal rendering dell'interfaccia utente del browser.
| Anno | Avanzamento |
|---|---|
| 2018 | OOP-R disponibile su Android, Mac e Windows. |
| 2019 | OOP-D spedito. OOP-R spedito ovunque (tranne Canvas). SkiaRenderer è disponibile su Linux. |
| 2020 | SkiaRenderer è disponibile su Windows e Android. Vulkan è disponibile su Android. |
| 2021 | SkiaRenderer è stato rilasciato su Mac (e a breve ChromeOS). |
Definizioni dei termini riportati nel grafico in alto:
- OOP-D
- Compositore display fuori processo. La composizione dello schermo è lo stesso tipo di attività di un compositore del sistema operativo. "Fuori processo" significa farlo nel processo di Viz anziché nel processo di rendering della pagina web o nel processo dell'interfaccia utente del browser.
- OOP-R
- Raster fuori processo. Raster sta convertendo gli elenchi di visualizzazione in pixel. Fuori processo significa farlo nel processo di Viz anziché nel processo di rendering della pagina web.
- SkiaRenderer
- Una nuova implementazione del compositore display in grado di supportare l'esecuzione su una serie di diverse API GPU sottostanti come Vulkan, D3D12 o Metal.
Rendering del canvas accelerato e con thread
Questo è il progetto che ha reso possibile OffscreenCanvas.
| Anno | Avanzamento |
|---|---|
| 2018 | Invia Canvas fuori schermo. |
| 2019 | Fornire ImageBitmapRenderingContext. |
| 2021 | Spedisci OOP-R. |
VideoNG
VideoNG è un'iniziativa a lungo termine per offrire una riproduzione di video efficiente, affidabile e di alta qualità sul web.
| Anno | Avanzamento |
|---|---|
| 2014 | Introdotto un framework di rendering basato su Mojo. |
| 2015 | Project Butter e overlay video sono stati spediti per un rendering video più fluido. |
| 2016 | Spedite pipeline unificate di decodifica e rendering per Android e desktop. |
| 2017 | Rendering video con correzione del colore e HDR spediti. |
| 2018 | È stata fornita la pipeline di decodifica video basata su Mojo. |
| 2019 | Pipeline di rendering video basata su Surface spedita. |
| 2021 | Spedito il supporto per il rendering dei contenuti protetti in 4K su ChromeOS. |
Definizioni dei termini riportati nel grafico in alto:
- Mojo
- Un sottosistema IPC di nuova generazione per Chromium.
- Piattaforma
- Un concetto che fa parte della progettazione del progetto Viz.
Illustrazioni di Una Kravets.