javascript - please - WebGL y Chrome: la alta resolución hace que el rendimiento sea malo
enable javascript opera (1)
Sin incluir otras cosas aquí, como lo hice la última vez, todos los métodos de requestAnimationFrame están limitados a 60 fps , y solo pueden ser más bajos que eso.
Puede probarlo con este bit: http://cssdeck.com/labs/gvxnxdrh/ . Puedes modificar fps var tan alto como desees, pero la animación no irá más rápido que 60 fps en cualquier navegador que tenga en mi escritorio.
Tengo una aplicación creada con LibGDX. Puedo ejecutar la aplicación en el escritorio y funciona a 90 fps @ 1080p.
En Firefox se ejecuta a 40-50 fps @ 1080p (ventana maximizada).
En Chrome se ejecuta a 30 fps @ 1080p (ventana maximizada).
Sin embargo, en Chrome, si disminuyo la resolución, el rendimiento se duplica (a 60 fps). En Firefox esto no sucede. ¿Cuál puede ser la causa de esto?
Estoy usando webkitRequestAnimationFrame.
Como se muestra, sé que mi PC puede manejar bien la resolución.
Editar
Estoy tratando de aplicar los siguientes consejos, aunque parecen dirigidos principalmente a GPU móviles.
Fuente: https://wiki.mozilla.org/Platform/GFX/MobileGPUs#Memory_Bandwidth
Siempre llame a glClear inmediatamente después de glBindFramebuffer
Consulte el documento Adreno 200, sección 3.2.1: "es imperativo (a) usar borrados cuando se cambian los Objetos de Frame Buffer (FBO) para evitar que el controlador intente guardar / restaurar los contenidos GMEM, y (b) siempre borrar la profundidad -buffer al inicio de un cuadro ".
Eso tiene sentido, por lo que siempre debemos hacerlo. Concretamente, esto significa que deberíamos hacer un glClear después de cada llamada a glBindFramebuffer, idealmente justo después de ella, o al menos antes de cualquier draw-call.
Los enlaces de framebuffer son caros
El cambio de las fuerzas de enlace de framebuffer resuelve inmediatamente la representación del framebuffer actual. Por lo tanto, es importante ordenar la representación para minimizar los enlaces de framebuffer. El documento Adreno 200, Sección 3.2.4, tiene una explicación útil.
Editar
Lo anterior no hizo una notable diferencia.
Editar
Tengo la sensación de que este problema surge debido al compilador GLSL. No tengo mucho conocimiento sobre el tema, pero creo que GLSL para OpenGL ES está compilado para GLSL regular, con algún código específico del navegador. Podría ser que Chrome compile menos de lo óptimo y haga que el sombreado de fragmentos ralentice el programa a resoluciones más altas.
Si alguien tiene algunos consejos sobre cómo asegurarse de que esta compilación esté optimizada, podría probar eso y ver si soluciona el problema.
Editar
El problema no parece prevalecer en Chrome en Windows con un chipset Intel HD graphics 4000+. Versión en cromo: 40.0.2214.111 m. Baja resolución: 45fps ~. Alta resolución: 30 fps constante.
Mi caso de prueba original fue con Chrome en Ubuntu con un GTX 650. La versión de Chrome se agregará más adelante.
Editar
Versión de Chrome que muestra este problema: 40.0.2214.111 (64 bits) en Ubuntu en una tarjeta gráfica GTX 650.
Editar
En la misma PC con GTX 650, bajo Windows 7, la misma aplicación se ejecuta a 60 fps de manera constante en Chrome. Dado que en Ubuntu, la aplicación compilada para Java funciona bien a 90 fps, creo que no puede ser un problema de controlador de Linux, sino que es un problema con la versión de Chrome para Linux.
Editar
He enviado un informe de error a Chrome sobre esto.