Grundsatzfrage Energieverbrauch Screen - mobile Geräte

[stahli]

Mal eine grundsätzliche Frage:

Wenn ich auf einem mobilen Gerät ein Bild im Vollbild (bzw. im gesamten Formular) darstellen möchte und dort einen kleinen Bereich zyklisch wechseln will (z.B. einen blinkenden Strich als Cursor malen), ist es dann stromsparender, nur den kleinen Bereich immer wieder zu übermalen oder kann man auch das gesamte Abbild auf die Zeichenfläche kopieren (ohne Cursor) und den Strich im nächsten Zyklus dazu malen.

Mir geht es hier nur mal Interesse halber darum, was auf mobilen Geräten im Zusammenhang mit einer GUI besonders energiefressend ist. (Auch ggf. bezüglich FMX.)

[p80286]

Zitat von stahli:

Mir geht es hier nur mal Interesse halber darum, was auf mobilen Geräten im Zusammenhang mit einer GUI besonders energiefressend ist.

Nach dem was ich bisher gehört/gelesen habe, die GUI/das Bild. Stromsparen kannst Du wohl nur durch Verzicht auf die Anzeige erreichen. ggf. kann man ein paar Promille aus hardwarefreundlichem Bildaufbau heraus kitzeln (sofern man überhaupt an die Doku kommt) aber die Anzeigehelligkeit bis zur volkommenen Schwärzung sollte am effizentesten sein.

Gruß
K-H

[stahli]

Hmm...

Es ist ja offensichtlich so, dass native Apps energieschonend laufen und FMX viel Energie zieht (mal davon ausgehend, dass beide Apps nichts besonderes zu berechnen haben, also quasi nur die GUI aktiv ist).

Also dachte ich, FMX zeichnet sich vielleicht ständig neu, was native Apps nicht tun. Könnte ja sein.

Aber wenn ein nativer Cursor blinkt muss ja auch ständig etwas neu gezeichnet werden. Insofern hätte ja zumindest der Screen schon immer etwas zu tun, um sich aktuell zu zeichnen.

Oder liegt der FMX-Leistungsverbrauch einfach an dem ineffektiven Neuzeichnenberechnen der Controls und gar nicht an der Formular-Abbildaktualisierung im Display?

Oha ... ich weiß ja noch nicht mal, wie ich hier eine vernünftige Fragen formulieren soll...

[mkinzler]

FMX zeichnet alles mit GPU Unterstützung. iese benötigt relativ viel Strom. Ein FMX Programm ist eher ein "Spiel", welches ja auch den Akku leersaugt.

[Mavarik]

Zitat von mkinzler:

FMX zeichnet alles mit GPU Unterstützung. iese benötigt relativ viel Strom. Ein FMX Programm ist eher ein "Spiel", welches ja auch den Akku leersaugt.

Hast Du das getestet oder ist das eine Vermutung?

Das Betriebssystem selber muss ja auch die Elemente zeichnen... Ich sehe da erst mal keinen Unterschied... Warum soll das Routine A aus dem Betriebssystem besser machen als Routine B aus der FMX RTL...

Es kann höchsten sein, dass die RTL das anders oder öfter macht.. Aber auch das habe ich bisher nicht getestet.

Man müsste mal 2 Programm mit exakt der geleichen Funktionalität neben einander stellen...

Mavarik

[mjustin]

Zitat von Mavarik:

Zitat von mkinzler:

FMX zeichnet alles mit GPU Unterstützung. iese benötigt relativ viel Strom. Ein FMX Programm ist eher ein "Spiel", welches ja auch den Akku leersaugt.

Hast Du das getestet oder ist das eine Vermutung?

Das Betriebssystem selber muss ja auch die Elemente zeichnen... Ich sehe da erst mal keinen Unterschied... Warum soll das Routine A aus dem Betriebssystem besser machen als Routine B aus der FMX RTL...

Es kommt auf das Gerät an - es gab in früheren Android Versionen die Option, die Verwendung der GPU für das UI Rendering zu erzwingen. Das das auch Nachteile haben konnte wurde in einem XDA Artikel erwähnt. Zitiert u.a. auf Stackoverflow:

Zitat:

"On certain devices, GPU consumes more power the CPU, hence you may observe 5-15% lower battery life with option enabled."

http://android.stackexchange.com/que...eloper-options

[Sherlock]

FMX rendert alles mit OpenGL. Rendern fasst das Berechnung und Zeichnen eines grafischen Objekts zusammen. Im Fall von FMX wird dazu eine Grafik-Bibliothek verwendet, die das zwar gut macht, aber eigentlich nicht so sehr für GUIs gedacht ist, sondern eher für 3D Szenen. Dieser Overhead bedeutet mehr involvierte Bibliotheken das bedeutet mehr Rechenleistung und das wiederrum führt zu Stromverbrauch.
Ein OS hat für das Zeichnen von Controls dedizierte Methoden, die das auf die effizienteste Weise tun, ganz einfach weil man dem Anwender eine schnelle Oberfläche (Stichwort: responsive) geben möchte. Da liegen wenige Zwischenschritte bzw. Bibliotheken zwischen nativem Control im Programm erzeugen und nativem control auf dem Display anzeigen das beudeutet weniger Stromverbrauch.

Zusammengefasst: FMX für Controls schlechter als native Controls. Sowohl optisch, als auch durch den inhärent größeren Strombedarf.

Aber: Es ist deutlich einfacher plattformübergreifend mit FMX zu entwicklen, das ist ein wirklich großes Plus.

O'Neill

[Mavarik]

Zitat von Sherlock:

FMX rendert alles mit OpenGL. Rendern fasst das Berechnung und Zeichnen eines grafischen Objekts zusammen. Im Fall von FMX wird dazu eine Grafik-Bibliothek verwendet, die das zwar gut macht, aber eigentlich nicht so sehr für GUIs gedacht ist, sondern eher für 3D Szenen. Dieser Overhead bedeutet mehr involvierte Bibliotheken das bedeutet mehr Rechenleistung und das wiederrum führt zu Stromverbrauch.
Ein OS hat für das Zeichnen von Controls dedizierte Methoden, die das auf die effizienteste Weise tun, ganz einfach weil man dem Anwender eine schnelle Oberfläche (Stichwort: responsive) geben möchte. Da liegen wenige Zwischenschritte bzw. Bibliotheken zwischen nativem Control im Programm erzeugen und nativem control auf dem Display anzeigen das beudeutet weniger Stromverbrauch.

Da gebe ich Dir recht, ohne es wirklich getestet zu haben... Aber wie groß ist der Unterschied...

Oder braucht eine XCode Anwendung schon weniger Strom im Ruhezustand als FMX...?
Und im Betrieb?

Von wie viel Prozent sprechen wir hier?

Und wie sieht es aus mit Android? Hier würde ich sogar schätzen, dass ein Darvik Anwendungen die Interpretiert werden muss - weil nicht nativ - sogar mehr Strom brauchen
als eine FMX mit nativen Arm7-Code...

Hat das mal jemand getestet?

Mavarik

[mjustin]

Zitat von Mavarik:

Und wie sieht es aus mit Android? Hier würde ich sogar schätzen, dass ein Darvik Anwendungen die Interpretiert werden muss

Android übersetzt Apps schon direkt bei der Installation in native Apps - http://www.areamobile.de/specials/26...e-im-vergleich

[Mavarik]

Zitat von mjustin:

http://www.areamobile.de/specials/26...e-im-vergleich

Zitat von LINK:

Google hat mit Android 4.4 Kitkat die neue Runtime ART (Android RunTime) eingeführt, von der sich der Hersteller für die Zukunft große Vorteile verspricht. Ausprobieren kann man ART schon, voreingestellt ist aber immer noch der Vorgänger Dalvik.

OK ist aber auch erst neu und i.d.R. nicht aktiviert... Aber egal...

Alle Strom Behauptungen sind für mich weiterhin ungetestet und eher gefühlt...