2012-04-20 6 views
7

Ich habe einen Film-Player basierend auf FFmpeg erstellt. Es funktioniert gut. Die Decodierung ist ziemlich schnell, auf LG P970 (Cortex A8 mit Neon) habe ich durchschnittlich 70 fps mit 640 x 424 Auflösung Videostream inklusive YUV2RGB Konvertierung. Es gibt jedoch einen Engpass. Es ist auf Leinwand gezeichnet.Wie die Leistung der Bitmap-Zeichnung auf Android

Ich benutze jnigraphics native Bibliothek, um Bilddaten in die Bitmap auf der nativen Seite zu füllen, und dann zeichne ich diese Bitmap auf Canvas in SurfaceView. Es ist ein ziemlich einfacher und gebräuchlicher Ansatz, aber die Zeichnung benötigt 44 ms für Bitmap mit 640 x 424 Auflösung, was fps auf 23 reduziert und diese Technik unbrauchbar macht ... Es braucht viel mehr als die gesamte A/V-Frame-Decodierung!

Gibt es eine Methode, um Bitmaps deutlich schneller zu zeichnen? Ich würde es vorziehen, komplett im nativen Code mit OpenGLES 2 zu rendern, aber ich habe gelesen, dass es auch slow sein könnte. Was nun? ...

Wie kann ich Bitmaps so schnell wie möglich rendern?

+0

Gibt es keine Möglichkeit, direkt von systemeigenem Code auf den Puffer von SurfaceView zuzugreifen? Camera Preview macht das afaik. – zapl

+0

AFAIK nein, zumindest kein Standard Weg mit NDK. Natürlich ist es möglich, mit Android-Quellen zu verknüpfen, aber es würde Probleme mit der Kompatibilität verursachen ... – vitakot

Antwort

3

Zeichnen Sie sie in GLES1.x. Sie müssen GLES2 nicht verwenden, da Sie keine oder zumindest nicht im Zusammenhang mit Ihrer Frage Shader verwenden, die der Hauptgrund für die Verwendung von GLES2.x wären. Aus Gründen der Einfachheit wäre GLES1.x also ideal. Alles, was Sie tun müssen, ist den Bytepuffer auf den Bildschirm zu zeichnen. Auf meinem Galaxy S (Vibrant) dauert das ungefähr 3ms. Die Größe des Bytes [] in meinem Hintergrundbild ist 800x480x3 oder 1152000, was wesentlich größer ist als das, mit dem Sie arbeiten.

Ich glaube, diese Anleitung sollte Sie in die richtige Richtung weisen.

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

Was den Begriff der Leinwand von der nativen Code zugreifen, würde ich das ganz und folgen Sie eine OpenGL-Implementierung nur vermeiden, indem sie alles auf GPU so viel wie möglich ausgelagert.

+0

Danke, Sie haben Recht; Ich werde zurück zu OpenGLES1.x wechseln. Ich habe keine Erfahrung mit OpenGL, also meine Annahme war die neuere ist besser. Ich habe den Artikel bereits in dem von Ihnen bereitgestellten Link gelesen. Eigentlich glaube ich, dass ich alle verwandten Artikel gelesen habe, die Google für mich finden konnte, sogar für die iOS-Plattform ... Nach einem ganzen Tag der Recherche bin ich immer noch ein bisschen verloren. – vitakot

+0

Beide Versionen greifen auf die gleiche Hardware zu. Die Power in 2.0 kommt von der zusätzlichen Hardware, auf die Sie Zugriff haben (die Shader-Prozessoren). In diesem Licht denke ich, es ist schwer zu sagen, dass man besser oder schlechter ist, es ist normalerweise so einfach wie die Entscheidung, was man erreichen muss. –

2

Ich erinnere mich während der Replica Island Präsentation während GoogleIO der Designer sagte, dass die Verwendung der OpenGL 'draw_texture' Erweiterung glDrawTexfOES der schnellste Weg war, um auf den Bildschirm zu blitzen, und deutlich schneller als Zeichnen nur regelmäßige Quads mit Texturen angefügt (ich bin vorausgesetzt, Sie verwenden OpenGL).

Sie können die Textur nicht drehen, aber es klingt nicht so, als ob Sie das brauchen.

+0

Sie haben Recht, ich interessiere mich nicht für die Rotation. Ich habe ein nettes Beispiel mit OpenGLES1.x (https://github.com/richq/glbuffer) gefunden, welches die erwähnte Funktion benutzt. – vitakot

Verwandte Themen