2015-02-17 9 views
25

Ho un'applicazione creata con LibGDX. Posso eseguire l'applicazione sul desktop e funziona a 90 fps @ 1080p.WebGL e Chrome: l'alta risoluzione crea cattive prestazioni

Su Firefox viene eseguito a 40-50 fps a 1080p (finestra ingrandita).

Su Chrome viene eseguito a 30 fps @ 1080p (finestra ingrandita).

Tuttavia su Chrome, se si riduce la risoluzione, le prestazioni si raddoppiano (a 60 fps). Su Firefox questo non succede. Quale può essere la causa di questo?

Sto usando webkitRequestAnimationFrame.

Come illustrato, so che il mio PC può gestire bene la risoluzione.

Modifica

Sto cercando di applicare i suggerimenti di seguito, anche se sembrano destinate a GPU mobili per lo più.

Fonte: https://wiki.mozilla.org/Platform/GFX/MobileGPUs#Memory_Bandwidth

chiamare sempre glClear subito dopo glBindFramebuffer

Vedere l'Adreno 200 documenti, la sezione 3.2.1: "è imperativo (a) l'uso cancella quando si passa oggetti Buffer Frame (FBO) per evitare che il driver tenti di salvare/ripristinare i contenuti GMEM e (b) deselezionare sempre il depth-buffer all'inizio di un frame. "

Questo ha senso, quindi dovremmo sempre farlo. Concretamente, questo significa che dovremmo fare una glClear dopo ogni chiamata a glBindFramebuffer, idealmente subito dopo, o almeno prima di ogni chiamata a draw.

framebuffer attacchi sono costosi

Modifica delle vincolante framebuffer forze immediatamente risolvere il rendering del framebuffer corrente. Pertanto è importante ordinare il rendering per minimizzare i binding del framebuffer. Il documento Adreno 200, Sezione 3.2.4, ha una spiegazione utile.

Modifica

È possibile che questo non ha fatto una differenza notevole.

Modifica

Ho la sensazione che questo problema si pone a causa del compilatore GLSL. Non ho molte conoscenze in materia, ma credo che GLSL per OpenGL ES sia compilato su GLSL regolare, con qualche codice specifico del browser. Potrebbe essere che Chrome si compili meno del ottimale e causi l'ombreggiatura dei frammenti per rallentare il programma a risoluzioni più elevate.

Se qualcuno ha alcuni suggerimenti su come assicurarsi che questa compilazione sia ottimizzata, potrei provarlo e vedere se risolve il problema.

Modifica

Il problema non sembra prevalente in Chrome su Windows con una grafica HD chipset Intel 4000+. Versione di Chrome: 40.0.2214.111 m. Bassa risoluzione: 45 fps ~.Alta risoluzione: 30 fps costante.

Il mio caso di prova originale era con Chrome su Ubuntu con una GTX 650. La versione di Chrome verrà aggiunta in seguito.

Modifica

versione di Chrome che visualizza questo problema: 40.0.2214.111 (64-bit) su Ubuntu su una scheda grafica GTX 650.

Modifica

sullo stesso PC con GTX 650, in Windows 7, la stessa applicazione viene eseguita a 60fps costanti sotto Chrome. Poiché con Ubuntu l'applicazione compilata su Java funziona bene a 90fps, credo che non possa essere un problema con il driver Linux, ma piuttosto un problema con la versione Linux di Chrome.

Modifica

Ho mandato un bugreport a Chrome su questo.

+0

Hai provato a confrontare il chrome: // gpu/da Linux e Windows per vedere se hanno problemi diversi rilevati? Inoltre, controlla se Chrome/Ubuntu supporta l'accelerazione hardware. Inoltre, controlla se il problema su Chrome/Ubuntu è in realtà il rendering .. forse è qualcosa in un'altra parte del codice. Vorrei suggerire, forse è una buona idea inviare una mail alla [mailing list di Khronos Group su WebGL] (https://www.khronos.org/webgl/public-mailing-list/). – wendelbsilva

+1

Stai chiamando 'gl.getError()' o 'gl.readPixels' nel tuo ciclo di rendering? Entrambi uccideranno perf. Stai caricando grandi quantità di dati (come video)? In generale, si troverà WebGL più lento del nativo perché i canvas WebGL sono composti nella pagina web. Per una tela a schermo intero che è un'estrazione a schermo intero extra. Oltre a questa richiesta, AnimationFrame è limitato a 60 fps (o alla frequenza di aggiornamento del monitor). Se si desidera controllare l'ora, è necessario verificare quanti millisecondi sono stati utilizzati o lasciato ogni fotogramma, non quanti fotogrammi al secondo poiché il monitor non è in grado di visualizzarli. – gman

+2

Su Windows WebGL utilizza DirectX e gli shader HLSL transpiled tramite il [progetto ANGLE] (https://code.google.com/p/angleproject/). Prova a eseguire Chrome con il flag '--use-gl = desktop' (senza precedenti istanze di Chrome in esecuzione) e verifica se riscontri gli stessi problemi di prestazioni. Inoltre, senza fornire alcun dettaglio su ciò che la tua applicazione fa in termini di rendering di questa domanda è invendibile. Prendi in considerazione l'aggiunta del link alla segnalazione dei bug che hai presentato in quanto potrebbe aiutare gli altri. –

risposta

1

Escluso altre cose qui dentro, per quanto ero in esso l'ultima volta, tutti questi metodi requestAnimationFramesono ricoperto a 60fps, e può solo andare inferiore a quello.

È possibile testarlo con questo bit: http://cssdeck.com/labs/gvxnxdrh/. Puoi modificare fps var al livello che desideri, ma l'animazione non sarà più veloce di 60fps in qualsiasi browser che ho sul mio desktop.

+0

Non ho nulla a che fare con VSync. Per qualche motivo, a Chrome non piace aggiornare le finestre con risoluzioni elevate. Se ho una finestra ingrandita, è 20 fps. Finestra ingrandita con metà della risoluzione, ancora 20 fps. Tuttavia, se riduco a metà la finestra, aumenta immensamente l'fps. Firefox non visualizza questo problema. – RobotRock

+0

Non riesco a riprodurre questo comportamento ... Risoluzione Wat/dimensioni della finestra inizia a rompersi in chrome? – yergo

+0

Framerate è variabile con dimensioni della finestra (risoluzione) quando si dispone di un GPU limitato. Succede in un browser e non nell'altro, probabilmente a causa dell'implementazione di OpenGL. Per quanto riguarda la frequenza di requestAnimationFrame ... dipende dalla CPU e dalla velocità della GPU (vedi gli strumenti di sviluppo nel tuo browser, F12, per determinare quale sta causando la limitazione). Btw, FPS non è limitato a 60. Non sono sicuro che ci sia un limite, l'ho visto girare a 75 su un computer di fascia alta – DAG