Pronto per contenuti web di nuova generazione
Sono Chris Harrelson, responsabile ingegneristico del rendering (trasformazione di HTML e CSS in pixel) in Blink. Sono più di otto anni che mi occupo di vari aspetti legati alle prestazioni del rendering sul web, con l'obiettivo personale di fare tutto il possibile per rendere più veloce, semplice e affidabile fornire un'esperienza utente eccellente sul web. Sono felice di farti conoscere quello che abbiamo fatto in quel periodo per creare una nuova e all'avanguardia architettura del motore di rendering di Chromium. È stato un grande impegno e spero che ti piaccia saperne di più.
Nel 2021, completeremo in gran parte il processo di progettazione, costruzione e distribuzione di questa architettura. Chiamiamola RenderingNG, dato che è davvero un'architettura di rendering di nuova generazione con prestazioni molto superiori. RenderingNG è in corso da almeno otto anni e rappresenta il lavoro collettivo di molti sviluppatori dedicati di Chromium. Sprigiona un enorme potenziale per la prossima generazione di contenuti web veloci, fluidi, affidabili, adattabili e interattivi. È anche una base che ritengo definisce un nuovo standard minimo per tutti i motori di rendering web su cui gli sviluppatori possono fare affidamento.
Questo post è il primo di una serie in cui spiegheremo cosa abbiamo realizzato, perché lo abbiamo realizzato e come funziona. In questo primo post, iniziamo con:
- Il nostro obiettivo principale.
- La piramide del successo: i principi alla base del nostro lavoro e gli esempi pratici di questi principi.
- Le caratteristiche e le capacità rese possibili da RenderingNG.
- Una panoramica generale dei principali componenti del progetto di RenderingNG.
Stella polare
L'obiettivo principale di 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 le funzionalità inaffidabili o che causano problemi di rendering del sito.
Non dovrebbero esserci ostacoli misteriosi nelle prestazioni. Inoltre, non dovrai aggirare le funzionalità integrate mancanti.
Dovrebbe funzionare.
Credo che RenderingNG sia un enorme passo avanti verso l'obiettivo principale. Prima di RenderingNG, potevamo (e lo abbiamo fatto) aggiungere funzionalità di rendering e migliorare le prestazioni, ma faticavamo a renderle affidabili per gli sviluppatori e c'erano molte prestazioni inferiori. Ora abbiamo un'architettura che abbatte sistematicamente molti di questi problemi e sblocca funzionalità avanzate che prima non erano considerate fattibili. Il GDPR:
- Dispone di solide funzionalità di base in diverse combinazioni di piattaforme, dispositivi e sistemi operativi.
- Ha prestazioni prevedibili e affidabili.
- Massimizza l'utilizzo delle funzionalità hardware (core, GPU, risoluzione dello schermo, frequenza di aggiornamento, API raster di basso livello).
- Esegue solo il lavoro necessario per visualizzare i contenuti visibili.
- È dotato di supporto integrato per schemi di progettazione visiva, animazioni e interazioni di progettazione comuni.
- Fornisce agli sviluppatori API per gestire facilmente i costi di rendering.
- Fornisce punti di estensione della pipeline di rendering per i componenti aggiuntivi degli sviluppatori.
- Ottimizza tutti i contenuti: HTML, CSS, 2D Canvas, canvas 3D, immagini, video e caratteri.
Confronto con altri motori di rendering del browser
Gecko e Webkit hanno anche implementato la maggior parte delle stesse funzionalità architettoniche descritte in questi post del blog e, in alcuni casi, le hanno persino aggiunte prima di Chromium. Non è fantastico? Sebbene qualunque browser che diventi più veloce e affidabile sia motivo di festeggiamento e abbia un impatto reale, l'obiettivo finale è quello di migliorare la base di riferimento per tutti i browser, in modo che gli sviluppatori possano contare su di esso.
La piramide del successo
La mia filosofia è che il successo è il risultato prima del raggiungimento dell'affidabilità, poi del rendimento scalabile e, infine, dell'estensibilità.
Come in una piramide reale, ogni livello fornisce una solida base per il livello superiore.
Affidabilità
Per offrire esperienze utente complete e complesse, la prima cosa di cui abbiamo bisogno è una piattaforma solida. Le funzionalità principali e i concetti di base devono funzionare correttamente e continuare a funzionare nel tempo. Ed è altrettanto importante che queste funzionalità siano ben composte e che non abbiano strani comportamenti limite o bug.
Per questo motivo, l'affidabilità è la parte più importante di RenderingNG. L'affidabilità è il risultato di test validi, cicli di feedback di qualità, metriche e pattern di progettazione del software.
Per capire quanto sia importante per me l'affidabilità, abbiamo trascorso gran parte degli ultimi otto anni a cimentarsi proprio in questa parte. In primo luogo, abbiamo acquisito una profonda conoscenza del sistema, imparando dalle segnalazioni di bug dove si trovavano i punti deboli e correggendoli, eseguendo il bootstrap di test completi e comprendendo le esigenze di prestazioni dei siti e le limitazioni delle prestazioni di Chromium. Quindi, abbiamo progettato e implementato in modo accurato e in modo incrementale strutture di dati e pattern di progettazione chiave. Solo a quel punto eravamo pronti ad aggiungere primitive davvero di nuova generazione per il design reattivo, la scalabilità e la personalizzazione del rendering.
Ciò non significa che in quel periodo non sia stato migliorato nulla in Chromium. Infatti, è vero il contrario. In questi anni abbiamo assistito a un aumento costante e sostenuto dell'affidabilità e delle prestazioni con il refactoring e l'implementazione di 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 nell'ambito di 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, per questo motivo), 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 anche le metriche relative al superamento di più test nel tempo e all'aumento della compatibilità dei core.
I test della piattaforma Web sono un impegno collaborativo. Ad esempio, gli ingegneri di Chromium hanno aggiunto solo circa il 10% dei test WPT totali per le funzionalità di 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 software efficaci
Fornire un 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. Avremo molto altro da dire sulla progettazione del software di RenderingNG nei successivi post del blog.
Prestazioni scalabili
Ottenere grandi prestazioni, in termini di velocità, memoria e consumo energetico, è l'altro 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 prestazioni, ma prestazioni scalabili, un'architettura che offre prestazioni affidabili su macchine di fascia bassa e di fascia alta e su piattaforme di sistemi operativi diversi. Detto questo, lo scale up, che sfrutta tutto ciò che il dispositivo hardware è in grado di ottenere, e lo scale down, massimizzando l'efficienza e riducendo la domanda sul sistema quando necessario.
Per arrivarci, dovevamo sfruttare al massimo la memorizzazione nella cache, l'isolamento delle prestazioni e l'accelerazione hardware della GPU. Esaminiamoli uno alla volta. Per rendere l'argomento più concreto, pensiamo a come ciascuno di questi contribuisce al rendimento di un'interazione estremamente importante sulle pagine web: lo scorrimento.
Memorizzazione nella cache
In una piattaforma 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 in un browser è la cache HTTP, ma il rendering ha anche molte cache. La cache più importante per lo scorrimento sono le texture GPU e gli elenchi di visualizzazioni memorizzati nella cache, che consentono di scorrere in modo estremamente veloce, riducendo al minimo il consumo della batteria e il buon funzionamento su una varietà di dispositivi.
La memorizzazione nella cache contribuisce alla durata della batteria e alla frequenza fotogrammi dell'animazione per lo scorrimento, ma ancora più importante è che sblocca l'isolamento delle prestazioni dal thread principale.
Isolamento delle prestazioni
Sui computer desktop moderni non devi preoccuparti che le applicazioni in background rallentino quella in uso. Questo è dovuto al multitasking preventivo, che a sua volta è una forma di isolamento delle prestazioni per garantire che le attività indipendenti non si rallentano a vicenda.
Sul web, l'esempio migliore di isolamento delle prestazioni è lo scorrimento. Anche sui siti web con molto JavaScript lento, lo scorrimento può essere molto fluido, poiché viene eseguito in un thread diverso che non deve dipendere dal thread di JavaScript e layout. Ci impegniamo al massimo in RenderingNG per assicurarci che ogni possibile scorrimento sia organizzato in thread, mediante la memorizzazione nella cache che va oltre un semplice elenco di visualizzazione fino a situazioni più complesse. Gli esempi includono codice per rappresentare elementi con posizione fissa e fissa, listener di eventi passivi e rendering del testo di alta qualità.
Accelerazione GPU
La GPU velocizza notevolmente la generazione di pixel e il disegno sullo schermo: in molti casi, ogni pixel può essere disegnato in parallelo con ogni altro pixel, determinando un enorme aumento della velocità. Un componente chiave di RenderingNG è il raster GPU e il disegno ovunque. Questa operazione utilizza la GPU su tutte le piattaforme e tutti i dispositivi per accelerare il rendering e l'animazione dei contenuti web. Questo è particolarmente importante per i dispositivi di fascia bassa o quelli di fascia molto alta, che spesso hanno una GPU molto più potente rispetto ad altre parti del dispositivo.
Estensibilità: gli strumenti giusti per il lavoro
Una volta ottenute affidabilità e prestazioni scalabili, siamo pronti a sviluppare una vasta gamma di strumenti per aiutare gli sviluppatori a estendere le parti integrate di HTML, CSS e Canvas senza sacrificare le prestazioni e l'affidabilità difficili da ottenere.
che include API integrate e esposte a JavaScript per casi d'uso avanzati di progettazione reattiva, rendering progressivo, fluidità e reattività e rendering con thread.
Le seguenti API web aperte, sostenute da Chromium, sono state rese possibili da RenderingNG e in precedenza erano considerate inattuabili.
Sono stati tutti sviluppati con specifiche aperte e in collaborazione con partner web aperti, ingegneri di altri browser, esperti e sviluppatori web. Nei successivi post del blog, approfondiremo ognuno di questi aspetti e spiegare in che modo RenderingNG li rende possibili.
- content-visibility: consente ai siti di evitare facilmente il rendering del lavoro per i 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 canvas (sia l'API 2D Canvas sia WebGL) sul proprio thread per prestazioni eccellenti in modo affidabile. Questo progetto rappresenta anche un altro traguardo importante 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 a un singolo componente di disporre in modo reattivo il proprio layout, sbloccando un intero universo di componenti plug-and-play (attualmente un'implementazione sperimentale).
- Isolamento dell'origine. Consente ai siti di attivare un maggiore isolamento del rendimento tra gli iframe.
- Worklet del paint off-main-thread: offre agli sviluppatori un modo per estendere la modalità di visualizzazione degli elementi, con codice che viene eseguito sul thread del compositor.
Oltre alle API web esplicite, RenderingNG ci ha consentito di offrire diverse "funzionalità automatiche" molto significative che apportano vantaggi a tutti i siti:
- Isolamento dei siti: consente di inserire iframe multiorigine in processi della CPU diversi, per un migliore isolamento della sicurezza e delle prestazioni.
- Vulkan, D3D12 e Metal: sfruttano le 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 di cui siamo entusiasti sono:
- Animazioni con link a scorrimento.
- DOM nascosto, ma disponibile per la ricerca e accessibile.
- Transizioni di elementi condivisi:
- Layout personalizzato.
- compositing off-main-thread; disaccoppiamento in thread e compositing.
Progetti chiave che compongono RenderingNG
Di seguito è riportato un elenco dei progetti principali all'interno di RenderingNG. I successivi post del blog si approfondiranno ulteriormente.
CompositeAfterPaint
Disconnessi che effettuano la composizione da stile, layout e disegno, consentendo un'affidabilità e prestazioni prevedibili molto migliori, una velocità effettiva aumentata e un utilizzo di meno memoria senza sacrificare le prestazioni. È iniziato nel 2014 e terminerà quest'anno.
| Anno | Avanzamento |
|---|---|
| 2015 | Spedisci elenchi espositori. |
| 2017 | Spedisci nuova invalidazione. |
| 2018 | Alberi di proprietà navale parte 1. |
| 2019 | Alberi di proprietà navale parte 2. |
| 2021 | Spedizione del progetto completata. |
LayoutNG
Una riscrittura da zero di tutti gli algoritmi di layout, per una maggiore affidabilità e prestazioni più prevedibili. È iniziato nel 2016 e dovrebbe terminare quest'anno.
| Anno | Avanzamento |
|---|---|
| 2019 | Flusso del blocco delle spedizioni. |
| 2020 | Flex per la spedizione, editing. |
| 2021 | Spedisci tutto il resto. |
BlinkNG
Pulizia e refactoring sistematici del motore di rendering Blink in fasi della pipeline ben separate. Ciò consente una migliore memorizzazione nella cache, maggiore affidabilità e funzionalità di accesso di nuovo o ritardato, come visibilità dei contenuti e query sui container. È iniziato nel 2014 e ha subito un miglioramento incrementale ed è continuo da allora. Sarà completato nel 2021.
Accelerazione GPU ovunque
Uno sforzo a lungo termine per implementare la rasterizzazione della GPU, il disegno e l'animazione su tutte le piattaforme, sempre. L'accelerazione GPU offre 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. È iniziato nel 2014 e si è concluso nel 2020.
| Anno | Avanzamento |
|---|---|
| 2014 | Supporto di Canvas. Spediti su Android con attivazione. |
| 2016 | Disponibile su Mac. |
| 2017 | La GPU viene utilizzata in oltre il 60% delle visualizzazioni di pagina su Android. |
| 2018 | Disponibile su Windows, ChromeOS e Android Go. |
| 2019 | Rasterizzazione GPU con thread. |
| 2020 | Spedisci i contenuti Android rimanenti. |
Scorrimento in thread, animazioni e decodifica
Uno sforzo a lungo termine per spostare tutte le animazioni di scorrimento e che non stimolano il layout e la decodifica delle immagini fuori dal thread principale. È iniziato nel 2011 ed è ancora in corso.
| Anno | Avanzamento |
|---|---|
| 2011 | Supporto iniziale per scorrimento e animazione in thread. |
| 2015 | Compressione dei livelli. |
| 2016 | Scorrimento universale del overflow. |
| 2017 | L'immagine decodifica sul thread del compositor. |
| 2018 | Animazioni immagine nel thread del compositor. |
| 2020 | Sempre composita posizione fissa. |
| 2021 | Animazioni trasformazione percentuale e animazioni SVG. |
Visualizzazione
Un processo centralizzato di raster e disegno per Chromium che aumenta la velocità effettiva, ottimizza la memoria e consente un utilizzo ottimale delle funzionalità hardware. Offre inoltre 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. È iniziato nel 2016 e terminerà nel 2021.
| Anno | Avanzamento |
|---|---|
| 2018 | OOP-R disponibile su Android, Mac e Windows. |
| 2019 | OOP-D spedito. OOP-R spedito ovunque (tranne Canvas). SkiaRenderer fornito su Linux. |
| 2020 | SkiaRenderer fornito su Windows e Android. Vulkan è stato spedito su Android. |
| 2021 | SkiaRenderer fornito su Mac (e a breve su ChromeOS). |
Definizioni dei termini presenti nel grafico sopra:
- OOP-D
- Compositore di display out-of-process. La composizione di annunci display è lo stesso tipo di attività di un compositore del sistema operativo. "Fuori processo" significa che l'operazione si svolge nel processo di visualizzazione anziché nel processo di rendering della pagina web o nel processo dell'interfaccia utente del browser.
- OOP-R
- Raster fuori processo. Il raster sta convertendo gli elenchi display in pixel. "Fuori processo" significa che l'operazione si svolge nel processo di visualizzazione anziché nel processo di rendering della pagina web.
- SkiaRenderer
- Una nuova implementazione di composizioner display in grado di supportare l'esecuzione su una serie di diverse API GPU sottostanti, come Vulkan, D3D12 o Metal.
Rendering accelerato e in thread
È questo il progetto che ha messo in atto gli elementi architettonici che hanno reso possibile OffscreenCanvas. È iniziato nel 2015 e terminerà nel 2021.
| Anno | Avanzamento |
|---|---|
| 2018 | Spedisci contenuti OutscreenCanvas. |
| 2019 | Invia ImageBitmapRenderingContext. |
| 2021 | Spedisci OOP-R. |
VideoNG
Un impegno a lungo termine per garantire una riproduzione efficiente, affidabile e di alta qualità dei video sul web.
| Anno | Avanzamento |
|---|---|
| 2014 | È stato introdotto un framework di rendering basato su Mojo. |
| 2015 | Sono stati spediti Project Burro e overlay video per un rendering video più fluido. |
| 2016 | Spedito pipeline unificate di rendering e decodifica di Android e desktop. |
| 2017 | HDR e rendering video con correzione del colore fornito. |
| 2018 | Pipeline di decodifica video basata su Mojo fornita. |
| 2019 | Pipeline di rendering video basata sulla superficie fornita. |
| 2021 | Supporto del rendering dei contenuti protetti 4K su ChromeOS. |
Definizioni dei termini presenti nel grafico sopra:
- Mojo
- Un sottosistema IPC di nuova generazione per Chromium.
- Piattaforma
- Un concept che fa parte della progettazione del progetto Viz.
Conclusione
Non potrebbe essere più entusiasta del tasso di miglioramento del rendering sul web e su Chromium. Prevedo che il ritmo continuerà ad aumentare nei prossimi anni, poiché possiamo sviluppare sulla base delle solide basi di RenderingNG.
Continuate a seguirci per molti altri post futuri con maggiori dettagli sulla nuova architettura, come è nata e come funziona.
Foto del dispositivo di Eirik Solheim su Unsplash
Illustrazioni di Una Kravets.