2012-04-20 20 views
7

Stworzyłem odtwarzacz filmowy oparty na FFmpeg. To działa dobrze. Dekodowanie jest dość szybkie, na LG P970 (Cortex A8 z Neonem) mam średnią 70 fps przy strumieniu wideo o rozdzielczości 640 x 424, w tym konwersji YUV2RGB. Istnieje jednak jedno wąskie gardło. Rysuje na płótnie.Jak zwiększyć wydajność rysowania bitmap na Androidzie

Używam biblioteki natywnej jnigraphics do wypełniania obrazów w bitmapie w natywnej stronie, a następnie rysuję tę mapę bitową na płótnie w SurfaceView. Jest to dość proste i powszechne podejście, ale rysunek zajmuje 44 ms dla bitmapy z rozdzielczością 640 x 424, która redukuje fps do 23 i sprawia, że ​​ta technika jest bezużyteczna ... Zajmuje znacznie więcej niż całe dekodowanie ramki A/V!

Czy istnieje metoda znacznie szybszego narysowania bitmap? Wolałbym renderować całkowicie w natywnym kodzie przy użyciu OpenGLES 2, ale przeczytałem też, że może to być slow. Co teraz? ...

Jak mogę renderować bitmapy tak szybko, jak to możliwe?

+0

nie ma sposobu na uzyskanie dostępu do bufora SurfaceView bezpośrednio z natywnego kodu? Podgląd kamery robi to afaik. – zapl

+0

AFAIK nie, przynajmniej nie ma standardowego sposobu korzystania z NDK. Oczywiście, możliwe jest połączenie ze źródłami Androida, ale powodowałoby to problemy z kompatybilnością ... – vitakot

Odpowiedz

3

Narysuj je w GLES1.x. Nie musisz używać GLES2, ponieważ nie będziesz używał, a przynajmniej nie w kontekście twojego pytania, dla shaderów, które byłyby głównym głównym powodem używania GLES2.x. Dla uproszczenia GLES1.x byłby idealny. Wszystko, co musisz zrobić, to narysować bajtbuffer na ekranie. Na mojej Galaxy S (Vibrant) zajmuje to około 3ms. Rozmiar bajta [] w mojej tapecie to 800x480x3 lub 1152000, który jest znacznie większy niż to, z czym pracujesz.

Uważam, że ten przewodnik powinien wskazywać właściwy kierunek.

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

chodzi o pojęcie dostępu płótno z natywnego kodu, chciałbym po prostu uniknąć całkowicie, a następnie implementację OpenGL przenosząc wszystko na GPU jak najwięcej.

+0

Dzięki, masz rację; Przejdę z powrotem do OpenGLES1.x. Nie mam doświadczenia z Open GL, więc moje założenie było lepsze. Przeczytałem już artykuł w linku, który podałeś. Właściwie to chyba musiałem przeczytać wszystkie powiązane artykuły, które Google mógł znaleźć dla mnie, nawet na platformę iOS ... Po całym dniu badań wciąż jestem trochę zagubiony. – vitakot

+0

Obie wersje mają dostęp do tego samego sprzętu. Moc w wersji 2.0 pochodzi z dodatkowego sprzętu, do którego masz dostęp (procesorów cieniowania). W tym świetle uważam, że trudno powiedzieć, że jedno jest lepsze lub gorsze, zwykle jest tak proste, jak podjęcie decyzji, co należy osiągnąć. –

2

Przypominam sobie podczas prezentacji Repliki Island podczas GoogleIO projektant powiedział, że używanie OpenGL "draw_texture" rozszerzenie glDrawTexfOES było najszybszym sposobem na blit do ekranu, i znacznie szybciej niż rysowanie zwykłych quadów z teksturami (jestem zakładając, że korzystasz z OpenGL).

Nie można obrócić tekstury, ale nie brzmi tak, jak tego potrzebujesz.

+0

Masz rację, nie dbam o rotację. Znalazłem ładny przykład używając OpenGLES1.x (https://github.com/richq/glbuffer), który wykorzystuje wspomnianą funkcję. – vitakot

Powiązane problemy