2012-06-27 4 views
7

Sto eseguendo il rendering di oggetti tramite OpenGL e ottenuto un buon framerate liscio di 60 fps nella maggior parte delle situazioni. UNTIL Faccio qualcosa di pesante in un thread in background, come prelevare materiale da un'API REST, elaborarlo e aggiungere oggetti al grafico (cose a bassa priorità, mi interessa di più della fluidità dell'interfaccia utente). Il renderer si fermerà quindi per un periodo molto lungo, fino a 1 secondo (all'incirca finché viene eseguito il thread in background), quindi riprenderà come se nulla fosse accaduto. L'ho notato perché è stata avviata un'animazione allo stesso tempo e rimane bloccata per questo periodo. Il thread in background è impostato su priorità minima e la garbage collection richiede fino a 100-200 ms, ma non tutto il secondo. Quando imposto un punto di debug in qualsiasi punto dell'attività di background, il rendering continua perfettamente, senza ritardi.Android: pause di rendering OpenGL quando attività in background pesante in esecuzione

È possibile che il mio thread in background pesante abbia fame nel thread OpenGL? Se sì, cosa posso fare?

+0

Quale GPU stai testando? –

+0

Sembra sospettosamente come [questa traccia delle prestazioni] (http://stackoverflow.com/q/9612959/1262542) ... –

+0

Non so che GPU, è un Galaxy Nexus. Vado a testarlo sul simulatore quando torno a casa. – manmal

risposta

1

Naturalmente! Una GPU ha bisogno di essere alimentata dai dati, e ciò è fatto dalla CPU. Quindi, se qualcosa nei colli di bottiglia del sistema, come l'I/O o l'elaborazione della CPU, non è possibile alimentare la GPU. Ad esempio, l'animazione viene tradizionalmente eseguita sulla CPU. Questo è il motivo per cui sul PC si ottengono molti giochi con frame rate più alti con gli stessi chip grafici ma con diverse CPU.

Concordo anche sul fatto che la creazione di profili è un'ottima idea. Se è possibile, suggerirei la creazione di profili per verificare che si tratti effettivamente della chiamata REST o se la chiamata REST è una delle molte cose

Una cosa che ho notato dell'elaborazione REST, e questo è successo a me. Poiché REST a volte elabora un sacco di stringhe e se non si utilizza StringBuilder, si può finire per sparpagliare un sacco di garbage collection. Tuttavia, non sembra che tu stia ottenendo questo.

+1

Quindi, perché lo schedulatore dovrebbe poter inserire un thread in background prima di alimentare la pipe della GPU? Non ha alcun senso. Se è così, perché gli ingegneri di Google non hanno solo conferito a quel thread di rendering una priorità più alta? – manmal

+0

A volte è Java che deve liberare RAM, specialmente nel caso di una chiamata REST, che tende a fare un po 'di elaborazione delle stringhe –

+1

Ho già detto che la garbage collection non può essere il problema qui, perché le pause del GC non sono così lungo. Sono più come 100-200ms al massimo, non 1,5 secondi. – manmal