Prestazioni WebGL

WebGL ha una reputazione negativa: molti sviluppatori pensano che WebGL sia lento e incapace di gestire grafica 3D complessa. Tanti esempi dimostrano che non è vero, eppure l’esperienza degli sviluppatori continua a rafforzare questa idea.

L’hardware che esegue il codice WebGL non viene limitato nei browser. Allora perché gli sviluppatori credono che sia impossibile renderizzare grafica 3D veloce sul web?

Questo articolo ti guiderà attraverso le migliori pratiche per le prestazioni di WebGL e ti mostrerà come ottenere un rendering 3D veloce sul web.

CPU vs GPU 

In un’applicazione 3D, parte del codice viene eseguito sulla CPU e parte su hardware accelerato, ossia la GPU.

WebGL è progettato per permettere l’uso della GPU per accelerare le applicazioni grafiche sul web. WebGL può quindi essere inteso come un insieme di funzioni che inviano lavoro all’hardware grafico e ne recuperano il risultato.

Il codice che crea lavoro per la GPU viene eseguito sulla CPU e, per WebGL, lo controlliamo tramite JavaScript.

Sovraccarico del Browser 

Poiché uno degli obiettivi del browser è proteggere l’utente da siti web potenzialmente pericolosi, verrà verificata la sicurezza di ogni chiamata WebGL effettuata dal sito tramite JavaScript. Inoltre, il processo che esegue il codice del sito deve essere isolato, e qualsiasi chiamata da e verso questo processo deve essere convertita in un formato trasmissibile, chiamato “marshalling”.

Sia il marshalling che la verifica delle chiamate WebGL del sito comportano un lavoro aggiuntivo che introduce un costo prestazionale, rispetto alla stessa chiamata in un ambiente nativo.

Evitare le Chiamate WebGL 

Per ottenere prestazioni ottimali con WebGL, dovremmo evitare di utilizzare chiamate con un elevato sovraccarico. Puoi facilmente individuare quali chiamate sono particolarmente costose profilando la tua applicazione WebGL.

Di seguito alcune chiamate che risultano sorprendentemente costose:

• getError()
• getParameter()
• getBufferParameter()

Un ottimo modo per evitare queste chiamate è effettuare il tracking dello stato WebGL e ridurre i controlli di errore nelle versioni di produzione della tua applicazione WebGL.

Evitare le Chiamate di Disegno 

Il segreto per eccellenti prestazioni WebGL è ridurre al minimo il numero di chiamate di disegno. Una chiamata di disegno è qualsiasi funzione che utilizza una delle seguenti funzioni WebGL:

• drawArrays()
• drawElements()
• drawArraysInstanced()
• drawElementsInstanced()
• drawBuffers()
• drawRangeElements()

Ci sono molti modi per farlo. Ad esempio, usando una chiamata che disegna molti oggetti invece di chiamare una funzione molte volte per disegnare gli stessi oggetti. Puoi usare l’instancing per renderizzare una grande quantità dello stesso mesh o il WEBGL_multi_draw per renderizzare molti oggetti diversi con lo stesso shader.

I motori 3D spesso includono una funzione chiamata “batching”, che unisce molte chiamate in un’unica chiamata WebGL. Wonderland Engine porta questo concetto a un livello estremo, dove scene con decine di migliaia di oggetti dinamici vengono renderizzate in meno di dieci chiamate di disegno automaticamente.

Le prestazioni WebGL su mobile sono particolarmente sensibili al numero di chiamate di disegno.

Evitare le Chiamate di Disegno (Mobile) 

Abbiamo inserito questa sezione due volte per sottolineare l’importanza: su mobile, le chiamate di disegno sono fondamentali anche senza il sovraccarico del browser. Anche costruendo nativamente con Unity o direttamente con GLES, è importante mantenere basso il numero di chiamate di disegno.

Se il tuo obiettivo è avere eccellenti prestazioni WebGL su mobile, è essenziale prestare particolare attenzione alle chiamate di disegno.

WebGL su Safari 

Su Safari (sia iOS che MacOS), ci sono altre chiamate WebGL che comportano un sovraccarico sorprendentemente elevato, ad esempio:

• bufferSubData()

Presta particolare attenzione all’uso dei Buffer di Uniformi quando ottimizzi per Safari.

JavaScript 

Il linguaggio utilizzato per interagire con le API del browser, come WebGL, è JavaScript. Il principale responsabile delle prestazioni di JavaScript è il Garbage Collection, che trova e rimuove automaticamente la memoria non più necessaria.

Il processo di Garbage Collection può rendere le prestazioni delle applicazioni WebGL imprevedibili e inaffidabili, poiché non hai controllo su quando avverrà. Di conseguenza, spesso si verifica in momenti inopportuni, causando balbuzie nel rendering e dando l’impressione di scarse prestazioni, anche se il codice è ben ottimizzato.

Per ottenere framerate stabili, adotta un approccio rigoroso nello scrivere JavaScript che eviti la produzione di garbage.

iOS Safari e Memoria 

Le app WebGL che funzionano bene su Safari sono rare. Le prestazioni di WebGL su Safari presentano ulteriori sfide. Abbiamo scritto un post dettagliato su come ottimizzare per Safari.

Limiti di Memoria 

Su iOS, c’è un’altra sfida: le schede del browser hanno memoria molto limitata, soprattutto sui dispositivi iPhone più vecchi. Se superi i limiti di memoria, la scheda potrebbe ricaricarsi o bloccarsi. Poiché gli iPhone utilizzano memoria unificata, la RAM per CPU e GPU è condivisa e sia le texture che i dati del buffer, così come la memoria JavaScript o WebAssembly, contribuiranno al limite.