Najlepszy sposób na rysowanie bitmap przy odświeżaniu 60 FPS

Trochę zawisłem w temacie rysowania bitmap za pomocą onDraw w Androidzie. Mianowicie, robię coś źle, ponieważ gradualnie rośnie zużycie zasobów podczas działania apki.
Dlatego chciałbym zapytać: czy znacie jakiś dobry sposób na rysowanie bitmap, które mają być update'owane z szybkością 60 klatek na sekundę? Wczoraj czytałem, że mógłby do tego się nadać OpenGL ES (czy jak to się zwie), ale dziwi mnie to, że muszę tworzyć przestrzeń trójwymiarową, żeby rysować dwuwymiarowe bitmapy...

Jakieś sugestie?

beaver.xv napisał(a):

Mianowicie, robię coś źle, ponieważ gradualnie rośnie zużycie zasobów podczas działania apki.

Źle to zrobili designerzy decydując się reimplementację JVM na prockach mobilnych ale tego już nie zmienisz (choć zawsze możesz przenieść się na iOS).

Dlatego chciałbym zapytać: czy znacie jakiś dobry sposób na rysowanie bitmap, które mają być update'owane z szybkością 60 klatek na sekundę? Wczoraj czytałem, że mógłby do tego się nadać OpenGL ES (czy jak to się zwie), ale dziwi mnie to, że muszę tworzyć przestrzeń trójwymiarową, żeby rysować dwuwymiarowe bitmapy...

To się robi żeby ominąć to co powyższe (czyli JVMa i jego narzut) i gadać bezpośrednio z GPU.

Jakieś sugestie?

To zależy... Jeśli potrzebujesz modyfikować to na żywo to OpenGL, jak nie to przerzuć to w rastry (offscreen rendering + tiling + cache) i będzie szybciej i ekonomiczniej.

beaver.xv napisał(a):

Wczoraj czytałem, że mógłby do tego się nadać OpenGL ES (czy jak to się zwie), ale dziwi mnie to, że muszę tworzyć przestrzeń trójwymiarową, żeby rysować dwuwymiarowe bitmapy...

Dobrze przeczytałeś. Nie chodzi tu nawet o grafikę 3d, tylko użycie wyspecjalizowanego hardware, które jest szybsze w tych specyficznych zadaniach i zużywa mniej prądu.
Generalnie jak masz cokolwiek bardziej skomplikowanego graficznie to użycie OpenGL na mobilce jest wręcz obowiązkowe.

loza_prowizoryczna napisał(a):

beaver.xv napisał(a):

Mianowicie, robię coś źle, ponieważ gradualnie rośnie zużycie zasobów podczas działania apki.

Źle to zrobili designerzy decydując się reimplementację JVM na prockach mobilnych ale tego już nie zmienisz (choć zawsze możesz przenieść się na iOS).

Dlatego chciałbym zapytać: czy znacie jakiś dobry sposób na rysowanie bitmap, które mają być update'owane z szybkością 60 klatek na sekundę? Wczoraj czytałem, że mógłby do tego się nadać OpenGL ES (czy jak to się zwie), ale dziwi mnie to, że muszę tworzyć przestrzeń trójwymiarową, żeby rysować dwuwymiarowe bitmapy...

To się robi żeby ominąć to co powyższe (czyli JVMa i jego narzut) i gadać bezpośrednio z GPU.

Jakieś sugestie?

To zależy... Jeśli potrzebujesz modyfikować to na żywo to OpenGL, jak nie to przerzuć to w rastry (offscreen rendering + tiling + cache) i będzie szybciej i ekonomiczniej.

JVM nie ma tu nic do rzeczy. Kiedyś implementowałem na iOS wyświetlanie filmiku (konwersja YUV do RGB). Próba zrobieni tego na CPU kończyła się zużcyiem procesora na 100% i framerate na poziomie 5 klatek.
Przerobienie tego na OpenGL załatwiło sprawę (zużycie zasobów na poziomie <5%).

loza_prowizoryczna napisał(a):

Źle to zrobili designerzy decydując się reimplementację JVM na prockach mobilnych ale tego już nie zmienisz (choć zawsze możesz przenieść się na iOS).

Czyli na iOS jest to lepiej rozwiązane? :D
Docelowo apka będzie też na iOS, ale nie wiem, czy jednocześnie mogę tworzyć apki na obie platformy...

Czego potrzebuję? Jedynie możliwości szybkiego wyświetlania kilku bitmap jako kafelki na wyświetlaczu (60 FPS, co klatkę nowa bitmapa, jeśli zmieniły się dane). Do tego jeszcze skalowanie i aspect ratio.

Skąd masz te dane? Jakie jest źródło zmian?

Pytam, bo to może pomóc ustalić optymalny sposób rysowania. I np. potencjalną możliwość oddelegowania rysowania do shadera. Albo może nie powinieneś tworzyć bitmapy, tylko powinieneś wielokąty. Ale to wszystko zależy, co robisz. Chyba, że faktycznie masz bitmapy, które idą gotowe skądś, a ty je tylko renderujesz.

(przy czym od razu mówię, że na mobilkach się nie znam, natomiast mam doświadczenie w WebGL, który jest zgodny z OpenGL ES, przynajmniej tak mówi specyfikacja).

Dane idą z apki postawionej na windowsie, która z kolei ciągnie te same dane z innej apki, do kodu której nie mam dostępu. Taki "adapter". Zastanawiałem się, czy lepiej przesyłać te dane JSON'em, czy może pakując je do 6-obajtowych paczek (dla każdej danej). Ale to nie w tym rzecz. W prototypie przy rysowaniu na zwykłym canvasie apka gradualnie zabierała coraz więcej zasobów - teraz chcę tego uniknąć.
Większość wskaźników (bo apka będzie wyświetlać wskazania na przyrządach) to będą linie rysowane czasem pod różnymi kątami.

MarekR22 napisał(a):

JVM nie ma tu nic do rzeczy. Kiedyś implementowałem na iOS wyświetlanie filmiku (konwersja YUV do RGB). Próba zrobieni tego na CPU kończyła się zużcyiem procesora na 100% i framerate na poziomie 5 klatek.
Przerobienie tego na OpenGL załatwiło sprawę (zużycie zasobów na poziomie <5%).

Nie wiem kiedy to było ale do takich przekształceń na CPU lepiej użyć narzędzi które wspierają wektoryzację out-of-box. Teoretycznie narzutu nie powinno być dużego bo najkosztowniejsza operacja CPU<->GPU czyli kopiowanie bufora nie występuje (zunifikowany model pamięci) a synchro z FPS możesz załatwić sobie CADisplayLinkiem. W praktyce... skłaniałbym się że taka sama operacja na Metalu będzie szybsza ;)

@beaver.xv: GPU jest dedykowane do tego typu operacji które potrzebujesz wiec nie ma co się zastanawiać, tylko trzeba poszukać tutka do tej technologii którą używasz + dopisek "opengl" :D
Robienie tego na CPU podpada pod skrajne marnowanie zasobów i na pewno objawi się cieplejsza obudowa telefonu

Wczoraj puściłem pierwsze testy na OpenGL w wersji 2.0 i póki co na razie nie widzę, żeby po kilku minutach wykorzystanie rosło. Jest na tym samym poziomie (~13% procka, pamięć zależnie od urządzenia, a prądożerność low)