[Gelöst] remotecontrol + SVG Icons = langsam beim Wechsel des Layouts

[sw]

Hallo,

ich möchte am Bildschirm eine Fernbedienung darstellen, die abhängig vom Kontext ihr Aussehen ändert.

Ich nutze das Modul 95_remotecontrol.
Ich habe mir entsprechend dem Wiki in der 99_myUtils.pm eigene Layouts definiert (18 Zeilen, 5 Spalten, 39 Tasten, da ich einige Plätze nicht belege)
Ich verwende SVG Icons, für die ich auch jeweils eine Farbe spezifiziere.

Grundsätzlich funktioniert das.

Mit

Code Auswählen Erweitern


set meineFernbedienung layout meinLayout1

und

Code Auswählen Erweitern


set meineFernbedienung layout meinLayout2

kann ich zwischen den Ansichten umschalten.

Der Browser verliert dabei aber die Verbindung zu fhem; verbindet sich nach einigen Sekunden wieder. Damit dauert das Umschalten einfach zu lange.
Am Rechner kann es nicht liegen, dieses Testsystem liegt auf einen Core i7.

Wenn ich testweise zu den mitgelieferten Layouts (samsung, itunes) umschalte, sehe ich keine spürbare Verzögerung und vor allem keinen Verbindungsabbruch. Diese Layouts verwenden png Icons, deshalb habe ich die SVG Icons als Ursache im Verdacht.

Bevor ich jetzt aufwändig die SVGs in PNGs konvertiere:
Hat jemand eine Idee, was da schief geht?
Übersehe ich etwas?

[rudolfkoenig]

SVG-Icons werden ins .HTML direkt eingefuegt, damit ist der Inhalt der ausgelieferten .html deutlich groesser, als bei .pngs, wo nur die Link-Adressen spezifiziert werden. Weiterhin kann der Browser so die .pngs Cachen. Beim Umfaerben muss FHEM auch noch den Inhalt aller .SVGs mit einem regexp bearbeiten.

Setze mal "attr global mseclog" und "attr WEB verbose 4", und schau in FHEM-Log nach, wie lange FHEM mit der Auslieferung der Seite beschaeftigt ist. Entweder ist FHEM zu langsam, oder der Browser braucht zu lange um SVG zu malen.

[sw]

Hallo Rudi,

intuitiv hatte ich nicht erwartet, das "die paar" SVGs eine solche Lastspitze verursachen.
Mit Deinen Erläuterungen wird es aber plausibel.
Dazu kommt, das die Zielumgebung natürlich deutlich schwächer ist als mein Entwicklungsrechner; sich das Problem also eher noch verschärfen wird. Ich werde also morgen mal zum Test meine Layouts auf irgendwelche schon vorhandenen PNGs umrüsten und - wenn das dann den erwarteten Erfolg bringt - meine SVGs in PNGs konvertieren.


Zu akademischen Zwecken hier trotzdem ein Log von einem Layoutwechsel.
Dabei hatte ich drei Browserfenster offen (2 Mal WEB Frontend, einmal Floorplan)

Wie sieht man jetzt, ob fhem oder der Browser die Verzögerung verursacht?

Code Auswählen Erweitern


2017.03.08 21:08:09.320 4: WEB_127.0.0.1_48440 POST /fhem&detail=rc_mm_Remote&dev.setrc_mm_Remote=rc_mm_Remote&cmd.setrc_mm_Remote=set&arg.setrc_mm_Remote=layout&val.setrc_mm_Remote=Off; BUFLEN:0
2017.03.08 21:08:09.404 4: WEB_127.0.0.1_48440 GET /fhem?detail=rc_mm_Remote&fw_id=; BUFLEN:0
2017.03.08 21:08:09.423 4: name: /fhem?detail=rc_mm_Remote&fw_id= / RL:24616 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2017.03.08 21:08:09.541 4: WEB_127.0.0.1_48440 GET /fhem?cmd={ReadingsVal(%22rc_mm_Remote%22,%22.remotecontrol%22,%22%22)}&XHR=1; BUFLEN:0
2017.03.08 21:08:09.541 4: name: /fhem?cmd={ReadingsVal(%22rc_mm_Remote%22,%22.remotecontrol%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.03.08 21:08:09.542 4: WEB_127.0.0.1_48440 GET /fhem?cmd={AttrVal(%22rc_mm_Remote%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2017.03.08 21:08:09.542 4: name: /fhem?cmd={AttrVal(%22rc_mm_Remote%22,%22room%22,%22%22)}&XHR=1 / RL:31 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.03.08 21:08:09.629 4: WEB_127.0.0.1_48440 GET /fhem?XHR=1&inform=type=status;filter=rc_mm_Remote;since=1489003688;fmt=JSON&fw_id=138×tamp=1489003689628; BUFLEN:0
2017.03.08 21:08:14.396 4: Connection accepted from WEB_127.0.0.1_48470
2017.03.08 21:08:14.397 4: WEB_127.0.0.1_48470 GET /fhem?XHR=1&inform=type=status;filter=room=Multimedia;since=1489003637.149;fmt=JSON&fw_id=116×tamp=1489003694395; BUFLEN:0
2017.03.08 21:08:14.416 4: Connection accepted from WEB_127.0.0.1_48472
2017.03.08 21:08:14.417 4: WEB_127.0.0.1_48472 GET /fhem/floorplan/MMWohnzimmer?XHR=1&inform=type=status;filter=fp_MMWohnzimmer=.%2B;iconPath=MMWohnzimmer;since=1489003637.795;fmt=JSON&fw_id=undefined×tamp=1489003694400; BUFLEN:0
2017.03.08 21:08:21.158 4: Connection accepted from WEB_127.0.0.1_48476
2017.03.08 21:08:21.159 4: WEB_127.0.0.1_48476 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2017-03.log; BUFLEN:0


[rudolfkoenig]

FHEM denkt zw. GET und drauffolgenden name (das ist ein Bug, sollte $FW_wname sein, habs gerade behoben) nach. D.h. bei der Detail-Ansicht 19ms, und schickt 24.6kB an komprimierten Daten.

Daran "kaut" der Browser 118ms lang nach, bevor die Frage nach dem aktuellen Werten der set und attr Felder kommt.

[sw]

So, ich habe die letzten Tage viel experimentiert und eine für mein Problem praktikable Lösung gefunden.

Mein Ziel ist ein Floorplan, über dem ich meine Multimediaausrüstung steuere.
Dazu zeigt der Floorplan die besagte remotecontrol an und z.Zt. 11 Dummys (die per devStateIcon ebenfalls als farbiges SVG Icon dargestellt werden)

Bei einem Kontextwechsel (z.B. dem Einschalten einer Multimedia Szene) werden einige SVG Icons der Dummys ausgetauscht und die remotecontrol bekommt ein neues Layout zugewiesen (ebenfalls auf SVG Icons basierend).

Es stört mich nicht, wenn dieser Kontextwechsel einige 100ms dauert.
Leider kam es beim Kontextwechsel bisher meist zu einem "Connection lost ..."; und damit dauerte es dann mehrere Sekunden, bis der Floorplan die neuen Icons anzeigte - das war nicht praktikabel.
Als ich die remotecontrol testweise mit deutlich weniger Tasten definiert habe, blieb das "Connection Lost ..." aus, aber ich brauche nun einmal die 39 Tasten (plus meine Dummys...).

Als Lösung schicke ich jetzt direkt nach dem Kontextwechsel einen Browser-Reload hinterher.
Nicht sehr elegant, funktioniert aber sehr gut und ist hinreichend schnell (trotz der ganzen farbigen SVG Icons). Auch auf einem langsamen, ältlichen Tablet ist die Geschwindigkeit praktikabel nutzbar.
Ich werde den Floorplan noch in eine eigene FHEMWEB Instanz auslagern - dann sind andere Seiten von dem Browser-Reload nicht betroffen (zur Erklärung: ich habe mehrere fest installierte Tablets, es sind also immer mehrere Browser aktiv)