Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest
-
Das kann mit vielen anderen Faktoren zu tun haben - wurde der Browser komplett geschlossen? Läuft zu dem Zeitpunkt noch etwas Anderes im Hintergrund usw.
So lässt sich das auf keinen Fall nachvollziehen - außer, man nutzt das gleiche System einmal mit Version x und das andere mit Version y.
Wie gesagt - an der Animations-Logik hat sich nichts geändert. Auch rechnet das System viel mehr, wenn die Animation langsamer läuft.@SKB Der Browser wurde jeweils neu gestartet. Auf dem Gerät läuft nur noch ein MQTT-Broker, im Hintergrund tut sich da nicht viel.
Mit 0.8.1 ist der Sparmodus tatsächlich deutlich sparsamer (CPU und Stromaufnahme des Windows-Tablets) als der Sparmodus mit 0.8.2 (siehe oben).
Ich habe nun mit 0.8.1 die Punkte von Länge 5 und Abstand 5 auf 10 und 24 geändert. So ist es nicht so "hektisch".
Aber irgendwas ist an der neuen Version ja schon anders, sonst würde ich das nicht so deutlich sehen. Was ist denn genau der Unterschied Normalmodus/Geringe Leistung? CSS vs. JS?
-
@SKB Der Browser wurde jeweils neu gestartet. Auf dem Gerät läuft nur noch ein MQTT-Broker, im Hintergrund tut sich da nicht viel.
Mit 0.8.1 ist der Sparmodus tatsächlich deutlich sparsamer (CPU und Stromaufnahme des Windows-Tablets) als der Sparmodus mit 0.8.2 (siehe oben).
Ich habe nun mit 0.8.1 die Punkte von Länge 5 und Abstand 5 auf 10 und 24 geändert. So ist es nicht so "hektisch".
Aber irgendwas ist an der neuen Version ja schon anders, sonst würde ich das nicht so deutlich sehen. Was ist denn genau der Unterschied Normalmodus/Geringe Leistung? CSS vs. JS?
-
@koilapo an der Version ist auch weiterhin nichts anders - je öfter du auch fragst.
Zu deiner neuen Frage:
Ja, der Stromsparmodus nutzt Javascript und kein CSS.@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
an der Version ist auch weiterhin nichts anders - je öfter du auch fragst.
Ich beschreibe nur meine Beobachtung. Kann ja nichts dafür, dass es so ist.
Was ist mit der Beschreibung für 0.8.2 genau gemeint:
"Neu: Der Modus „Geringe Leistung“ wurde verbessert, indem die möglichen Animationsframes berechnet werden, anstatt statische Zeiten zu verwenden."
-
@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
an der Version ist auch weiterhin nichts anders - je öfter du auch fragst.
Ich beschreibe nur meine Beobachtung. Kann ja nichts dafür, dass es so ist.
Was ist mit der Beschreibung für 0.8.2 genau gemeint:
"Neu: Der Modus „Geringe Leistung“ wurde verbessert, indem die möglichen Animationsframes berechnet werden, anstatt statische Zeiten zu verwenden."
-
@koilapo Vorher wurde die Länge der Linie berechnet und anhand dessen die Zeit, welche die Animation benötigt.
Dies wurde durch die JavaScript Komponente
requestAnimationFrameersetzt!@SKB Danke, dann haben wir die Ursache ja wahrscheinlich schon:
The window.requestAnimationFrame() method tells the browser you wish to perform an animation. It requests the browser to call a user-supplied callback function before the next repaint.
-> call a user-supplied callback function before the next repaint
-> also 60 mal je Sekunde wird die Funktion aufgerufen gegenüber Null Aufrufen für einen statischen Wert. -
@SKB Danke, dann haben wir die Ursache ja wahrscheinlich schon:
The window.requestAnimationFrame() method tells the browser you wish to perform an animation. It requests the browser to call a user-supplied callback function before the next repaint.
-> call a user-supplied callback function before the next repaint
-> also 60 mal je Sekunde wird die Funktion aufgerufen gegenüber Null Aufrufen für einen statischen Wert.@koilapo Welche Ursache? Für eine höhere CPU Last? Nein, denn die Funktion ruft sich nicht 60 Mal pro Sekunde auf, sondern reserviert sich selbst für den nächsten repaint, was CPU schonender ist, als eine for-Schleife - das Bild wird eh 60 Mal die Sekunde neu gezeichnet. Das ist der Standard auf einem 60 Hertz Monitor.
-
@koilapo Welche Ursache? Für eine höhere CPU Last? Nein, denn die Funktion ruft sich nicht 60 Mal pro Sekunde auf, sondern reserviert sich selbst für den nächsten repaint, was CPU schonender ist, als eine for-Schleife - das Bild wird eh 60 Mal die Sekunde neu gezeichnet. Das ist der Standard auf einem 60 Hertz Monitor.
@SKB Vielleicht hängt die tatsächliche Effizienz vom Betriebssystem und Browser ab. Mit Edge unter Win10 läuft es jedenfalls ineffizienter mit requestAnimationFrame als mit der einfachen Schleife - ist jedenfalls meine Beobachtung/Messung.
Aber damit derselbe Energiefluss möglichst einheitlich auf verschiedenen Bildschirmen/Systemen läuft, ist Dein Weg schon sinnvoll.
-
@SKB Vielleicht hängt die tatsächliche Effizienz vom Betriebssystem und Browser ab. Mit Edge unter Win10 läuft es jedenfalls ineffizienter mit requestAnimationFrame als mit der einfachen Schleife - ist jedenfalls meine Beobachtung/Messung.
Aber damit derselbe Energiefluss möglichst einheitlich auf verschiedenen Bildschirmen/Systemen läuft, ist Dein Weg schon sinnvoll.
@koilapo Ich würde an deiner Stelle einmal Chrome (auch Chromium wie Edge) oder Firefox (Webkit) ausprobieren. Die funktionieren aktuell am Zuverlässigsten beim EF.
Allerdings schaue ich gleich noch einmal, was sich noch optimieren lässt - habe da schon etwas im Kopf.
-
@koilapo Ich würde an deiner Stelle einmal Chrome (auch Chromium wie Edge) oder Firefox (Webkit) ausprobieren. Die funktionieren aktuell am Zuverlässigsten beim EF.
Allerdings schaue ich gleich noch einmal, was sich noch optimieren lässt - habe da schon etwas im Kopf.
-
@SKB Danke für den Tipp. Edge ist mit Abstand der schnellste Browser auf der Kiste, habe schon verschiedene ausprobiert. Chromium ist fast gleichauf.
@koilapo So, ich habe nun noch einmal etwas angepasst, um die Animation optimierter zu bekommen. Kannst gerne nochmal die Version von Github drüber installieren und deine Eindrücke mitteilen.
Ich denke, es sollte nochmals ein merklicher Unterschied da sein, machte bei mir in etwa 20-25% aus - je nachdem, wieviele Linien sichtbar sind. -
@koilapo So, ich habe nun noch einmal etwas angepasst, um die Animation optimierter zu bekommen. Kannst gerne nochmal die Version von Github drüber installieren und deine Eindrücke mitteilen.
Ich denke, es sollte nochmals ein merklicher Unterschied da sein, machte bei mir in etwa 20-25% aus - je nachdem, wieviele Linien sichtbar sind. -
@SKB Vielen Dank. Also ich merke keine Verbesserung im Sparmodus, aber im Normalmodus ist nun das Tempo nicht mehr einstellbar, es ist immer ziemlich langsam, egal welchen Wert ich dort eintrage. Vorhin ging das noch.
@koilapo Ich liebe es immer, wenn ich Updates herausbringe, das etwas nicht mehr geht.
Immer folgende Reihenfolge einhalten, wenn von Github installiert wird:
- von Github installieren
- Upload des Adapters vornehmen
- Browser mit Strg + F5 neuladen
Dann funktioniert auch alles wie vorher und eben besser ;)
-
@koilapo Ich liebe es immer, wenn ich Updates herausbringe, das etwas nicht mehr geht.
Immer folgende Reihenfolge einhalten, wenn von Github installiert wird:
- von Github installieren
- Upload des Adapters vornehmen
- Browser mit Strg + F5 neuladen
Dann funktioniert auch alles wie vorher und eben besser ;)
-
@SKB Danke, war wohl gecacht.
Nach wie vor erzeugt der Normalmodus deutlich weniger CPU-Last als der Sparmodus in 0.8.2. Wobei der Sparmodus in 0.8.1 am besten ist (außer vom Tempo).
-
@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
Dann wird dies wohl ein Problem mit dem Edge sein
Oder an irgendwas anderem auf dem nicht mehr ganz frischen Gerät, was auf neuen CPUs anders läuft. Das Teil ist ja leider nicht Win11 -kompatibel, aber eigentlich recht flott für den Zweck.
Schade, dass in der nächsten Version dann der alte JS-Modus nicht mehr vorhanden ist, aber soweit läuft 0.8.1 ja perfekt.
-
Ich kann mich nur wiederholen - Chome oder Firefox nutzen. Die interpretieren die Dinge am Besten. Ist ja egal, ob sie schnell sind oder nicht. Hauptsache sie kommen mit dem Code zurecht.
@SKB Habe es nochmal getestet: Chromium mit 0.8.2 Sparmodus: Ich schaffe es höchstens mal ab und zu unter 40% CPU-Auslastung.
Wenn ich hingegen Chromium mit 0.8.1 Sparmodus laufen lasse, bin ich meist sogar unter 20%. In Edge verhält es sich exakt gleich.
Also für mich funktioniert Dein altes Sparmodell deutlich besser, soll ja eigentlich auch für solche CPUs sein (m5-6Y54),
-
@SKB Habe es nochmal getestet: Chromium mit 0.8.2 Sparmodus: Ich schaffe es höchstens mal ab und zu unter 40% CPU-Auslastung.
Wenn ich hingegen Chromium mit 0.8.1 Sparmodus laufen lasse, bin ich meist sogar unter 20%. In Edge verhält es sich exakt gleich.
Also für mich funktioniert Dein altes Sparmodell deutlich besser, soll ja eigentlich auch für solche CPUs sein (m5-6Y54),
@koilapo Ich kann nicht alle CPU´s, Geräte, Hersteller, Modelle, Größen und was weiss ich noch alles abdecken.
Da hätte ich eine Library, die wahrscheinlich das Ausmaß der Anwendung sprengen würde, hätte keinen Job und Freizeit mehr, weil ich für 10% der Anwender 150% meiner Zeit gebe - und das kostenlos! -
@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
Dann wird dies wohl ein Problem mit dem Edge sein
Oder an irgendwas anderem auf dem nicht mehr ganz frischen Gerät, was auf neuen CPUs anders läuft. Das Teil ist ja leider nicht Win11 -kompatibel, aber eigentlich recht flott für den Zweck.
Schade, dass in der nächsten Version dann der alte JS-Modus nicht mehr vorhanden ist, aber soweit läuft 0.8.1 ja perfekt.
@koilapo sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
Das Teil ist ja leider nicht Win11 -kompatibel, aber eigentlich recht flott für den Zweck.
Dann würde ich überlegen, da ein schlankes aber aktuelles Linux drauf zu werfen.
-
@koilapo Ich kann nicht alle CPU´s, Geräte, Hersteller, Modelle, Größen und was weiss ich noch alles abdecken.
Da hätte ich eine Library, die wahrscheinlich das Ausmaß der Anwendung sprengen würde, hätte keinen Job und Freizeit mehr, weil ich für 10% der Anwender 150% meiner Zeit gebe - und das kostenlos!
Support us
469
Online32.7k
Benutzer82.5k
Themen1.3m
Beiträge