Dianne Hackborn (mai cognome fu più azzeccato), ingegnere di Google che lavora ad Android, stanca della cattiva informazione che gira in rete, puntualizza con un post su Google+ alcuni punti riguardanti il render grafico di Android.
Il post è molto interessante, visto che chiarisce dei fatti riguardanti una tecnologia che ormai, possiamo dirlo, è tra le mani di un vastissimo pubblico.
Vediamo insieme quali sono i punti in questione.
- Android ha sempre utilizzato l’accelerazione hardware per la rappresentazione grafica.
Sin dalla prima della versione 1.0 tutto il lavoro di window compositing è stato sempre fatto dall’hardware. Tutte le animazioni del sistema operativo (transizioni, pop-up, finestre di dialogo, ecc..) sono gestite direttamente a livello hardware. - Android ha storicamente fatto anche uso di software per renderizzare i contenuti di una finestra. Nell’esempio mostrato qui sotto sono rappresentate 4 finestre (n.b. la barra delle notifiche, la widget, lo sfondo e il menu). Se una delle 4 aggiorna il suo contenuto, allora (ma prima della versione 3.0) il contenuto viene ridisegnato tramite software. Tuttavia le altre finestre non vengono affatto ridisegnate e il re-compositing delle finestre è fatto a livello hardware. Allo stesso modo, ogni movimento interno alle finestre, come per esempio un menu che si muove su e giù, viene renderizzato tramite hardware.
- Per quanto riguarda la rappresentazione grafica all’interno di una finestra, non è necessario fare questa operazione tramite hardware per ottenere un rendering a 60 fps. Certamente questo dipende molto dal numero di pixel da mostrare e dalla velocità della CPU del dispositivo.
- Con la versione 3.0 di Android è stato introdotto la rappresentazione grafica all’interno di una finestra effettuata completamente dall’accelerazione hardware. Da questa versione in poi, se lo sviluppatore specifica nel manifest dell’applicazione android:hardwareAccelerated="true", tutte le rappresentazioni grafiche dentro le finestre verranno gestite dalla GPU. C’è una piccola differenza nella versione 4.0 di Android, e consiste nel fatto che le applicazioni che puntano specificatamente per questa versione di Android non dovranno più inserire l’opzione dell’accelerazione hardware nel manifest in quanto questa è abilitata di default. L’accelerazione hardware non viene forzata di default in ogni caso per una serie di ragioni:
- Alcune operazioni di disegno non vengono supportate bene dall’hardware cosa che rischia di mandare in crash le applicazioni.
- L’accelerazione hardware non è sempre un vantaggio. Per esempio iniziare ad utilizzare OpenGL in un processo sul Nexus S e il Galaxy Nexus costa circa 8MB di RAM che è davvero molto se si considera che la soglia massima di un processo dovrebbe essere 2MB. Ovviamente la RAM extra utilizzata viene tolta da altre cose, tipo il numero massimo di processi contemporaneamente, cosa che, potenzialmente, può portare ad un rallentamento generale del sistema.
- Dato quindi il consumo spropositato di RAM da parte di OpenGL, uno potrebbe anche non voler usare l’accelerazione hardware per il disegno. Ad esempio il team di sviluppo di Android sta adattando il codice di Android 4.0 al Nexus S facendo in modo di disabilitare l’accelerazione hardware in parte dell’interfaccia utente. In questo modo, senza che l’utente se ne accorga, c’è un risparmio notevole di RAM su un dispositivo il cui hardware non è in grado di supportare con beneficio l’accelerazione hardware per ogni cosa.
- L’accelerazione hardware poi non rappresenta la soluzione semplice e unica per avere un’interfaccia veloce e solida. Sono stati introdotte numerose funzionalità per supportare l’accelerazione hardware, come un miglioramento dello scheduling dei threads riguardanti il rendering del primo piano Vs. sfondo nella v. 1.6, riscrittura del sistema di input nella v. 2.3, miglioramento al garbage collection, e così via. Per ottenere 60fps ci sono 20 millisecondi a disposizione per gestire ogni frame, ed è sufficiente per esempio accedere al sistema della memoria flash nel thread che si sta occupando dell’interfaccia utente per introdurre un ritardo che ci fa uscire dalla finestra dei 20 millisecondi, specialmente se stiamo scrivendo sulla memoria flash.
- Nei confronti riguardanti lo scrolling di pagine web tra Android e iOS, la maggior parte delle differenze non sono dovute alla renderizzazione grafica attraverso accelerazione hardware. Originariamente Android trattava le pagine web come display list in continuo renedering sullo schermo, invece di usare le tiles. Il vantaggio di questo metodo è che zoomando lo schermo non si vedono mai artifatti dovuti alle tiles che non sono ancora state disegnate. Lo svantaggio è che se la grafica della pagina web è ricca e complessa, questo metodo porta ad una perdita di frame rate. A partire da Android 3.0 il browser utilizza le tiles, quindi può mantenere un frame rate costante durante lo scroll e lo zoom, con l’effetto negativo dovuto agli artifatti nel caso di tiles non ancora renderizzate. Le tiles stesse vengono renderizzate via software, cosa che dovrebbe avvenire anche per iOS.
- L’accelerazione hardware non fa sparire magicamente i problemi legati alle prestazioni del rendering. Esiste ancora un limite a ciò che la GPU può fare. Per ottenere il frame rate di 60fps Android 3.0 e le successive versioni, utilizzano alcuni trucchi. Uno tra questi è il processo di overlay per tutte le finestre, invece di copiare le stesse nel framebuffer della GPU. Un altro trucco è legato allo sfondo. Lo sfondo di Android è una finestra a se stante, quindi questa finestra viene costruita più larga di quanto è visualizzato in effetti sullo schermo. Il vantaggio è che scrollando tra le finestre, lo sfondo non necessita di nessuna operazione di rendering ma solo del movimento della finestra stessa. Dato che la finestra è in overlay non ha bisogno di essere renderizzata a schermo, tramite window compositing, dalla GPU.
- Con l’aumentare della risoluzione, riuscire a raggiungere 60fps dipende molto dalla velocità della GPU e, in particolar modo, dal bus della memoria della GPU. Bisogna tenere a mente che ci sono un sacco di situazioni in cui la CPU (specialmente grazie alle NEON instructions) può essere molto più veloce del bus della memoria.
Come potete vedere queste chiarificazioni sono molto tecniche e molto oneste. Conoscere questo genere di informazioni, anche per chi non è esattamente un programmatore hardware, può essere molto utile per avere un’idea di quali siano i processi che stanno dietro al funzionamento di una cosa specifica.
Se siete maggiormente interessati vi invito a leggere direttamente il post di Dianne Hackborn su Google+.
Via | Google+ [Dianne Hackborn]
Nessun commento:
Posta un commento