Koala - Adjust Energy flowchart animation

[Brett-S-OWB]

Die Animationsgeschwindigkeit der Linien im Energieflussdiagramm ist jetzt dynamisch direkt von der aktuellen Leistung des jeweiligen Systems abhängig. Der Wertebereich für die Geschwindigkeit wird dabei automatisch an die jeweils höchste aktuelle Leistungsaufnahme im System angepasst. Die Animation selbst wird nicht mehr über CSS, sondern vollständig im Script-Bereich der Komponente gesteuert.

Diese Umstellung war notwendig, da mit CSS-Animationen keine stufenlose und dynamische Anpassung der Animationsgeschwindigkeit möglich ist. Durch die Steuerung per JavaScript bleibt die Animation auch bei abrupten Leistungsänderungen jederzeit flüssig und synchron, ohne sichtbare Sprünge oder Neustarts, wie sie bei CSS-Animationen auftreten würden.

Forum topic: https://forum.openwb.de/viewtopic.php?p=135517#p135517

[Brett-S-OWB]

Commit: "Animation carried out in script section to avoid "animation skipping" - [fb491a5]
war nicht einsetzbar da JavaScript-Loop zu viel Rechenlast erzeugt.

Ich habe drei mögliche Lösungen für die Flow-Animation implementiert, jeweils als eigener Commit:

Option A – Rein CSS-basierte Keyframe-Animation
• Dauer wird per v-bind() dynamisch im CSS gesetzt.
• Sehr geringe CPU/GPU-Last.
• Funktioniert grundsätzlich in allen Browsern, zeigt aber leichte „Sprünge“ (Chrome/Firefox/Safari).
• Optisch akzeptabel

Option B – JavaScript-Loop (requestAnimationFrame)
• Die Animation wird komplett im Script mit requestAnimationFrame() berechnet.
• Frame-Rate auf 2 FPS begrenzt (vorher 30 FPS).
• Dadurch flüssig und stabil in allen Browsern, inklusive Safari.
• CPU - Last zu hoch für Raspberry-Pi - (JavaScript-Loop)

Option C – Dynamische CSS-Transitions (ohne Keyframes)
• Keine Keyframes; stattdessen wird nach jeder Bewegung per Transition (stroke-dashoffset) weiter animiert.
• JavaScript stößt nur den nächsten Transition-Schritt an (Chained Transitions).
• Geringe CPU-Last, deutlich besser als Option B.
• In Chrome/Firefox sehr flüssig, aber Safari zeigt weiterhin großeres sichtbares Springen die als animation nicht akzeptabel sind.

Fazit :

Nach Tests aller drei Varianten wurde Option A (reine CSS-Keyframes) ausgewählt.
Commit: "CSS-class per component - dynamic with v-bind - works in all browsers". - 0a79dff
Sie bietet die beste Kombination aus Browser-Kompatibilität, Stabilität und geringer CPU-Last.
Die kleinen Sprünge während der Animation sind in allen Browsern gleichmäßig und damit akzeptabel.
Option B wurde verworfen, da der JavaScript-Loop auf ressourcenschwachen Systemen wie dem Raspberry Pi zu CPU-intensiv ist.
Option C ist technisch interessant, funktioniert jedoch in Safari weiterhin sichtbar ruckelig und ist daher nicht universell einsetzbar.