performamnte Bitmap skalierungs Algorithmus gesucht

Jaiel

Jaiel

Dauergast
235
Hey ich möchte meine Bitmaps performant skalieren.

Das Problem ist dass ich einen horizontalen Slider in meiner app eingebaut habe der die Menüpunkte als Buttons darstellt.

Die Buttons werden dann auch skaliert nach folgendem schema

der Button der zur Auswahle steht ist groß dargestellt alle anderen 50% kleiner

wenn der User jetzt den slider bedient und sich die Positionen der Menuitems in der Liste ändert werden dann die buttons danach skaliert wie weit sie vom Menüpunkt 0 weg sind(dieser Menüpunkt ist ein Anker und auch der Punkt wo der jew Buttons dann aktiv zur Auswahl steht wenn der User draufklickt)

So jetzt das Schlimme an meiner Methode:

heir der Pseudo Code:
Code:
MenuItem
{
    member:
                  -bitmap
                  -...

    ...
}

For(MenuItem mI:mIList)
{
     -fülle die bitmap des mI folgender maßen:
         -hole die ressource aus dem res ordner
         -skalier die resource in Abhängigkeit von der relativen Entfernung zum Menüpunkt 0
         -überschreibe mI.bitmap
}

ich führe den Code nur aus wenn sich auch etwas verändert
ab einem bestimmten abstand haben die buttons immer diesselbe größe(ca 0.2*bildschirmbreite) deswegen skalier ich auch nur die die sich in diesem radius zwischen 0 und 20% befinden

die ressourcen sind png mit maßen 512x512


Problem: es laggt sehr sehr doll!!!

Kein Wunder wenn ich die resourcen immer wieder neu laden und neu skalieren muss....nciht nur der Ram ist dann voll sondern auch die CPU hat ganz schön was zu tun.

Mit png der größe 64x64 scheint es gut zu laufen wobei cih sagen muss dass ich ein Note 4 als Testgerät habe und der ist ja auch nciht gerade langsam

und trotzdem ächzt er bei 512x512.


man könnte jetzt auf die Idee kommen die ressourcen nciht neu zu laden sondern die Bitmaps wiederverwenden dann hätte man das decoden gespart.

jedoch verfärben sich dann die buttons weil ich schatteneffekte drin habe

bei dieser Methode werden die bitmaps allmählich immer dunkler bis sie schwarz sind je anchdem wie oft skaliert werden muss

das ist auch nciht so toll


hier ncoh meine Codehülle falls ihr nicht verstanden ahbt was ich meine:

PHP:
//Button1
mThread.Button1.bmp=Bitmap.createScaledBitmap(
				BitmapFactory.decodeResource(getResources(),R.drawable.button1),
				mThread.Button1.width,mThread.Button1.height,true);


//Button2
...


hat jemand ein Vorschlag es anders zu amchen?


unten ein screenie der euch ein groben überblick geben soll(ich hab jetzt schnell schwarze kreise erstellt in 64x64 um es zu testen aber die Auflösung ist sagen wir mal so für die katz das kann ich nicht bringen)
 

Anhänge

  • Screenshot_2015-03-14-01-26-33-1[1].png
    Screenshot_2015-03-14-01-26-33-1[1].png
    7,1 KB · Aufrufe: 164
Zuletzt bearbeitet:
Edit ich werde(morgen) mal mit android anti aliasing system rumspielen ob es mcih zufrieden stellt dann teste ich die Bitmaps nochmal bei verschieden auflösungen der Ressourcen wie gut das AA greift


trotzdem bin ich wieterhin offen für andere Vorschläge

Da zur Zeit bei mir nur die Idee besteht die ressourcen zu verkleinern also keine systematischen Änderungen
 
Ich würde in fixen Schritten Arbeiten beim Skalieren (also nur eine fixe endliche Anzahl an Zwischengrößen) und das ganze nur einmal berechnen und im Cache halten.
 
Ja ist auch eine Überlegung

Das würde CPU zeit sparen

Nur dann sEhen die übergange leider nicht mehr flüssig aus und ich laufe Gefahr ein outofmemory zu bekommen...

Es bleibt wohl vorerst dabei kleinere Ressourcen zu nehmen und einige Micro optimazatioNS im Code zu machen ...
 
Du kannst das entweder mit nativem code machen oder Renderscript. Beides sollte wesentlich performanter sein. Meine es gibt ein renderscript Musik cover Beispiel an das man sich anlehnen könnte
 
ich glaube bei android macht eine andere sprache keine performance verbesserungen da sollte man lieber bei java bleiben

aber ich schau mal nach einem geeigneten renderscript danke für den tipp
 
Lol natürlich ist nativer code wesentlich schneller als in der jvm. Gerade bei Bildern ist der unterschied enorm. Korrekte implementation natürlich vorausgesetzt.
 
Nur so als Gedanke: Was wäre denn, wenn du die Oberfläche in OpenGL umsetzt?

OpenGL ES | Android Developers
Dann müssten z.B. Skalierungen etc. hardwarebeschleunigt erfolgen.
 
Ich glaube die surfaceview die ich benutze wird ebenfalls hardwarebeschleunigt und ab api14 werden glaub ich alle zeicheniperationen von views accelerated
 
Ja, zu dem Schluss bin ich auch (nach etwas mehr überfliegen) gekommen.
 
OpenGl lohnt sich trotzdem. Gerade bei 3D nimmt das Framework viel Arbeit ab. Und ist sehr schnell. NDK würde ich nicht unbedingt einsetzen, außer dir liegt die Sprache. Android läuft nicht auf C, sondern in einem speziellen Bytecode. Nur weil man die Sprache des Compilers benutzt, wird das Programm nicht schneller. Google selber rät davon ab. Gründe langsamer und braucht mehr Speicherplatz.
Was sich immer lohnt, ist der Einsatz von Threads.
 
ja deswegen mein einwand das es nciht unbedingt schneller wird wenn ich c++ benutze oder C(eher c++ weil ich mcih in c nicht so gut auskenne) wäre auch nciht das größte problem. Aber bei grafik intensiven apps wie spielen oder bioldbearbeitungsprogrammen da ist an amnchen stellen die rechenintensiv sind schon von vorteil auf das NDK zurückzugreifen weil es einfach schneller geht den speicher manuell anzusteuern und bits per hand hin und her zu schieben.

Ich weiß auch nciht wie das jetzt mit dem neuen compiler von android ist der soll ja etwas schneller als die dalvik laufen und schon einen teil des code irgendwie beim installieren in byte kompilieren und nciht rein just in time kompiliert werden
was sich dann zwar auf die instalationsgröße auswirkt aber performance geht manchmal über alles vor allem da die speicherkapazitäten eh ansteigen werden in zukunft
 

Ähnliche Themen

J
Antworten
0
Aufrufe
562
JonHart
J
S
Antworten
5
Aufrufe
1.328
Smobbynaut
S
allesausbits
Antworten
22
Aufrufe
1.962
swa00
swa00
Zurück
Oben Unten