Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest
-
Eine Frage zum "Energiesparmodus für Animationen": Ich nehme an, dass dieser Modus JS statt CSS-Animationen nutzt. Allerdings habe ich nicht herausgefunden, an welcher Stelle ich die Geschwindigkeit einstellen kann. Wo genau, in welcher JS-Datei, müsste ich welchen Timer ändern, um das Tempo etwas zu drosseln? Danke!
-
Hallo Zusammen,
ich habe soeben eine neue Version auf Github veröffentlicht. Es ist die 0.8.2.Folgendes ist neu bzw. behoben:
- Behoben: Der Adapter wurde in der Übersicht des Begrüßungsbildschirms angezeigt (sollte nur in der Pro-Version verwendet werden) (#429)
- Behoben: Die Menüleiste zeigte beim ersten Öffnen des Arbeitsbereichs während der Tour-Ansicht eine Ladeanimation an.
- Behoben: Bei Verwendung der Animationsabhängigkeit „Punkte“ oder „Dauer“ war die Animation zu stark – die Übergänge wurden angepasst.
- Behoben: Bei der Animationsabhängigkeit „Punkte“ wurde nach dem Einschalten der Leitung mindestens ein Punkt angezeigt. Über den Schwellenwert kann das Erscheinen des ersten Punktes gesteuert werden.
- Behoben: Das Kontextmenü in der Live-Ansicht wurde ausgeblendet, wenn eine Berührungsbewegung erkannt wurde.
- Neu: Der Modus „Geringe Leistung“ wurde verbessert, indem die möglichen Animationsframes berechnet werden, anstatt statische Zeiten zu verwenden.
- Neu: Das Kontextmenü in der Live-Ansicht ist jetzt standardmäßig deaktiviert. Um es wieder zu aktivieren, ändern Sie dies in den Einstellungen.
Freudiges "fließen" mit der neuen Version ;)
-
Eine Frage zum "Energiesparmodus für Animationen": Ich nehme an, dass dieser Modus JS statt CSS-Animationen nutzt. Allerdings habe ich nicht herausgefunden, an welcher Stelle ich die Geschwindigkeit einstellen kann. Wo genau, in welcher JS-Datei, müsste ich welchen Timer ändern, um das Tempo etwas zu drosseln? Danke!
@koilapo sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
Eine Frage zum "Energiesparmodus für Animationen": Ich nehme an, dass dieser Modus JS statt CSS-Animationen nutzt. Allerdings habe ich nicht herausgefunden, an welcher Stelle ich die Geschwindigkeit einstellen kann. Wo genau, in welcher JS-Datei, müsste ich welchen Timer ändern, um das Tempo etwas zu drosseln? Danke!
Der Energiesparmodus läuft mit einer festen Zeit. Es ist nicht vorgesehen, die Dateien zu editieren, da sie bei einem Update wieder überschrieben werden.
-
@koilapo sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
Eine Frage zum "Energiesparmodus für Animationen": Ich nehme an, dass dieser Modus JS statt CSS-Animationen nutzt. Allerdings habe ich nicht herausgefunden, an welcher Stelle ich die Geschwindigkeit einstellen kann. Wo genau, in welcher JS-Datei, müsste ich welchen Timer ändern, um das Tempo etwas zu drosseln? Danke!
Der Energiesparmodus läuft mit einer festen Zeit. Es ist nicht vorgesehen, die Dateien zu editieren, da sie bei einem Update wieder überschrieben werden.
@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
Der Energiesparmodus läuft mit einer festen Zeit. Es ist nicht vorgesehen, die Dateien zu editieren, da sie bei einem Update wieder überschrieben werden.
Danke, das wäre mir egal, wenn ich das nach dem Update wiederholen müsste. Aber der normale Modus läuft auf meinem älteren Tablet einfach mit zuviel CPU-Last, der Energiesparmodus hingegen würde noch gut passen, doch der wirkt vom Tempo zu hektisch. Daher wäre es für mich kein Thema, da manuell einzugreifen, ich müsste nur wissen, wo. Bin leider bisher nicht fündig geworden.
PS: Gerade erst gesehen, dass es die 0.8.2 gibt. Darin ist es jetzt genau umgekehrt: Die normale Animation braucht jetzt deutlich weniger CPU-Leistung, dafür ist die Energiesparversion jetzt so ressourcenhungrig wie vorher die normale Animation.
PS2: Anscheinend ist es so, dass im Energiesparmodus immer bei einer Änderung die CPU-Last kurz stark hochgeht, also wenn eine Linie ein- oder umgeschaltet wird. Wird wohl die Berechnung der "möglichen Animationsframes" sein?
-
@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
Der Energiesparmodus läuft mit einer festen Zeit. Es ist nicht vorgesehen, die Dateien zu editieren, da sie bei einem Update wieder überschrieben werden.
Danke, das wäre mir egal, wenn ich das nach dem Update wiederholen müsste. Aber der normale Modus läuft auf meinem älteren Tablet einfach mit zuviel CPU-Last, der Energiesparmodus hingegen würde noch gut passen, doch der wirkt vom Tempo zu hektisch. Daher wäre es für mich kein Thema, da manuell einzugreifen, ich müsste nur wissen, wo. Bin leider bisher nicht fündig geworden.
PS: Gerade erst gesehen, dass es die 0.8.2 gibt. Darin ist es jetzt genau umgekehrt: Die normale Animation braucht jetzt deutlich weniger CPU-Leistung, dafür ist die Energiesparversion jetzt so ressourcenhungrig wie vorher die normale Animation.
PS2: Anscheinend ist es so, dass im Energiesparmodus immer bei einer Änderung die CPU-Last kurz stark hochgeht, also wenn eine Linie ein- oder umgeschaltet wird. Wird wohl die Berechnung der "möglichen Animationsframes" sein?
-
@koilapo Was ist denn da "hektisch"? Eine Strecke von 136 Positionen läuft etwa 2 Sekunden.
Allerdings könnte ich diese Geschwindigkeit auch variabel machen.
Schaue ich mir an!@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
Was ist denn da "hektisch"?
War in der 0.8.1 so, hektisch im Sinne von "schnell". Da ich die ganze Linie voll Punkte und 5-8 Linien habe, wirkt es bei dem Tempo hektisch.
Wenn das einstellbar ist, wäre das natürlich toll, sofern das einfach umsetzbar wäre. Im Prinzip könntest Du ja die vorhandene einstellbare "Dauer der Animation" nehmen und ggfls. um einen Faktor umrechnen.
-
@SKB sagte in Test Adapter Energiefluss-erweitert v0.8.x GitHub/Latest:
Was ist denn da "hektisch"?
War in der 0.8.1 so, hektisch im Sinne von "schnell". Da ich die ganze Linie voll Punkte und 5-8 Linien habe, wirkt es bei dem Tempo hektisch.
Wenn das einstellbar ist, wäre das natürlich toll, sofern das einfach umsetzbar wäre. Im Prinzip könntest Du ja die vorhandene einstellbare "Dauer der Animation" nehmen und ggfls. um einen Faktor umrechnen.
-
@koilapo Wenn Du möchtest, kannst Du einmal die Version direkt von Github laden und dann den Modus im Tab "Animation" anpassen.
-
@SKB Vielen Dank, das funktioniert.
Allerdings habe ich im Energiesparmodus jetzt eine leicht höhere CPU-Auslastung und höheren Stromverbrauch. Der 0.8.1 Energiesparmodus war da tatsächlich sparsamer gegenüber dem Normalmodus.
-
@koilapo An dem Modus ansich hat sich so gesehen nichts geändert.
Natürlich kann es sein, das die CPU-Last anhand der langsamen Zeit anders berechnet. -
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. -
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.
Support us
469
Online32.7k
Benutzer82.5k
Themen1.3m
Beiträge