Cómo aumentar el rendimiento del dibujo de mapas de bits en Android

Creé un reproductor de películas basado en FFmpeg. Funciona bien. La decodificación es bastante rápida, en LG P970 (Cortex A8 con Neon) tengo un promedio de 70 fps con una secuencia de video de resolución de 640 x 424, incluida la conversión YUV2RGB. Sin embargo, hay un cuello de botella. Está dibujando en Canvas.Cómo aumentar el rendimiento del dibujo de mapas de bits en Android

Utilizo la biblioteca nativa jnigraphics para rellenar los datos de imagen en el mapa de bits en el lado nativo y luego dibujo este mapa de bits en Canvas en SurfaceView. Es un enfoque bastante simple y común, pero el dibujo lleva 44 ms para mapa de bits con una resolución de 640 x 424 que reduce fps a 23 y hace que esta técnica no se pueda usar ... ¡Se necesita mucho más que la decodificación de cuadros de A/V!

¿Hay algún método para dibujar mapas de bits significativamente más rápido? Preferiría renderizar completamente en el código nativo usando OpenGLES 2, pero lo he leído también podría ser slow. ¿Y ahora qué ...?

¿Cómo puedo representar mapas de bits lo más rápido posible?

Fuente

2012-04-20 vitakot

¿no hay una forma de acceder al búfer de SurfaceView directamente desde el código nativo? La vista previa de la cámara hace esto afaik. – zapl

AFAIK no, al menos no forma estándar utilizando NDK. Por supuesto, es posible enlazar con fuentes de Android, pero podría causar problemas con la compatibilidad ... – vitakot

Dibujalos en GLES1.x. No necesita usar GLES2 ya que no tendrá uso, o al menos no en el contexto de su pregunta, para shaders, que sería la razón principal general de usar GLES2.x. Entonces, para simplificar, GLES1.x sería ideal. Todo lo que necesita hacer es dibujar el bytebuffer en la pantalla. En mi Galaxy S (Vibrante) esto toma alrededor de 3 ms. El tamaño del byte [] en mi fondo de pantalla es de 800x480x3 o 1152000, que es significativamente más grande que con lo que está trabajando.

Creo que esta guía debe orientarle en la dirección correcta.

http://qdevarena.blogspot.com/2009/02/how-to-load-texture-in-android-opengl.html

En cuanto a la noción de acceso a la lona de código nativo, sólo se evitaría que en conjunto y seguir una implementación de OpenGL mediante la descarga de todo para GPU tanto como sea posible.

Fuente

2012-04-20 17:31:45

Gracias, tienes razón; Volveré a pasar a OpenGLES1.x. No tengo experiencia con Open GL así que mi suposición era que cuanto más nuevo es mejor. Ya leí el artículo en el enlace que proporcionó. En realidad, creo que debo haber leído todos los artículos relacionados que Google pudo encontrar para mí, incluso para la plataforma iOS ... Después de un día entero investigando, todavía estoy perdido un poco. – vitakot

Ambas versiones tienen acceso al mismo hardware. La potencia en 2.0 proviene del hardware adicional al que tiene acceso (los procesadores de sombreado). Así que desde ese punto de vista, creo que es difícil decir que uno es mejor o peor, por lo general es tan simple como decidir lo que necesita lograr. –

Recuerdo que durante la presentación de Replica Island durante GoogleIO el diseñador dijo que usar la extensión OpenGL 'draw_texture' glDrawTexfOES era la forma más rápida de blitear la pantalla, y mucho más rápido que dibujar solo cuadrículas con texturas adjuntas (estoy asumiendo que estás usando OpenGL).

No se puede rotar la textura, pero no parece que la necesite.

Fuente

2012-04-20 17:44:33 Tim

Tienes razón, no me importa la rotación. Encontré un buen ejemplo usando OpenGLES1.x (https://github.com/richq/glbuffer) que usa la función que mencionaste. – vitakot

Cómo aumentar el rendimiento del dibujo de mapas de bits en Android

Respuesta

Cuestiones relacionadas