Warum ist TabletUI so langsam...

[grossmaggul]

Hallo,

ja, es ist eine ketzerische Frage, aber ich muß sie jetzt einfach mal stellen.
Ich habe mal testweise smartvisu installiert und bin erstaunt ob der Geschwindigkeit, die diese Oberfläche an den Tag legt, dagegen ist TabletUI wirklich eine lahme Schnecke und das besonders auf Tablets oder Smartfons.
Während smartvisu eine vollgepackte Seite in sekundenschnelle aufbaut, dauert das bei TabletUI schonmal 20 Sekunden und mehr bis alle Elemente angezeigt werden.

Was ist der Grund für diese Geschwindigkeitsdiskrepanz?

gm

[grossmaggul]

Da scheint es wohl keine Antwort drauf zu geben...

[M.Piet]

Hmmm ich finde auch das TBUI langsam ist. Es dauert Sekunden bis sich die Seite aufbaut. Oft sogar bis zu 5 Sekunden.
Ich hätte das jetzt auch den fehlenden Dampf des Pi geschoben. Einen Vergleich habe ich nicht, da ich nur TBUI als Frontend nutze.

[Eisix]

Hi,

die Geschwindigkeit beim laden finde ich nicht so kritisch, schlimmer ist das nach einer Weile die Verbindung abbricht und nach Aktivierung nicht wieder verbindet, was einen dann zu einem kompletten neu laden zwingt.

Hat jemand Erfahrungswerte ob das bei FUIP besser ist?

Gruß
Eisix

[dkreutz]

TabletUI ist sehr JavaScript-lastig und erfordert dementsprechend auch Resourcen auf der Client-Seite. Ein  Einsteiger/Mittelklasse-Tablet, was dann ggfs. auch nicht mehr topaktuell ist, kann da schon an die Grenzen kommen.

[grossmaggul]

Naja, selbst auf meinem Macbook Pro und einem 2017er iPad mit unterschiedlichen Browsern dauert es manchmal mehrere Sekunden bis die Seite aufgebaut wurde.

Ich frage mich halt, was macht smartvisu anders, daß es so schnell ist.

[amenomade]

Ich frage mich halt, was macht smartvisu anders, daß es so schnell ist.

smartvisu nutzt seinen eigenen Webserver mit PHP.

[Rewe2000]

Hallo,

ich hatte früher auch FTUI verwendet und mich über die langsame Geschwindigkeit immer geärgert, ich dachte irgend etwas an meiner Konfiguration passt nicht, deshalb habe ich an den Projekt nur mehr sehr langsam und sporadisch weitergearbeitet. Auch hatte ich immer große Probleme meine Objekte an die richtige Position unter HTML zu platzieren.

Vor einigen Monaten habe ich dann FUIP durch Zufall endekt und habe zwischenzeitlich mein Projekt komplett umgestellt und es obendrein noch massiv erweitert. Über langsame Geschwindigkeit kann ich mich nicht beklagen, selbst total überfrachtete und komplexe Seiten laufen auf dem Raspi3 absolut flüssig und schnell.
Ich verwende einige FUIP Elemente und sehr viele Objekte mit HTML Code, in dem FUIP eigenen HTML Objekten. Das einzige was langsam ist und den Raspi zum stehen bringt (bis 10-15 Sekunden) ist das übersetzen von HTML Code in das FUIP eigenen Code. Wurde dieser übersetzt ist alles wieder schnell und ohne jegliche Hänger.

Für weniger geübte HTML Freaks ist FUIP sehr gut geeignet und es lassen sich in kurzer Zeit sehr komplexe Seiten erstellen, ich möchte es nicht mehr vermissen.

Ich denke aber auch ein langsames FTUI sollte sich irgendwie beschleunigen lassen, vermutlich passt irgend etwas an der Konfiguration nicht, sonst hätten sich ja schon mehr Anwender über die langsame Geschwindigkeit beklagt.

Gruß Reinhard

[grossmaggul]

Ich denke aber auch ein langsames FTUI sollte sich irgendwie beschleunigen lassen, vermutlich passt irgend etwas an der Konfiguration nicht, sonst hätten sich ja schon mehr Anwender über die langsame Geschwindigkeit beklagt.

Mag sein, ich habe aber inzwischen einige Tipps hier aus dem Forum durch um FTUI zu beschleunigen und ich bin auch nicht der Einzige, der die Geschwindigkeit nicht so prickelnd findet. Suche mal hier im Bereich, da wirst Du einige Beiträge zu dem Thema finden.
FUIP habe ich mir mal angesehen, ist mir aber zu unflexibel und das Design spricht mich nicht an. Kann das so viel schneller sein als FTUI? Ist das nicht auf FTUI aufgebaut?

smartvisu nutzt seinen eigenen Webserver mit PHP.

O.K., das erklärt einiges.

[herrmannj]

Naja, selbst auf meinem Macbook Pro und einem 2017er iPad mit unterschiedlichen Browsern dauert es manchmal mehrere Sekunden bis die Seite aufgebaut wurde.

Ich frage mich halt, was macht smartvisu anders, daß es so schnell ist.

"Wir" haben an dem smartVisu Treiber "damals" ewig lange optimiert obwohl (und) die Anbindung (WS) vom ersten Augenblick auf speed ausgelegt war. Man muss für die Geschwindigkeit insofern unterscheiden, dass initial die Seite geladen wird (php) und dann die einzelnen Inhalte, also Button ist on oder off, via WS und JS nachgeladen werden. Erst wenn alles da ist, ist die Seite "fertig". Da hab ich Installationen gesehen die einige 100 Werte hatten. Selbst wenn der einzelne Wert dann nur ein paar ms ist, da kommt ganz schön was zusammen. Aber ist in sv halt optimiert.

[moonsorrox]

Ich arbeite auch mit FTUI un dhabe einen Intel-NUC als Servergerät, aber ich muß beklagen das es grottig langsam geworden ist bis sich die Seiten aufbauen.
Noch dazu muss ich z.B. wenn ich an FTUI arbeite mit dem FF, meinen Firefox Cache jedesmal leeren bevor er überhaupt eine Änderung anzeigt das finde ich bei Änderungen die ich grad zurzeit mache echt lästig.
Also ich denke die meisten haben sich an die Langsamkeit gewöhnt und wenn ein FTUI einiges an Größe erreicht wird es nicht besser.

[yersinia]

Noch dazu muss ich z.B. wenn ich an FTUI arbeite mit dem FF, meinen Firefox Cache jedesmal leeren bevor er überhaupt eine Änderung anzeigt das finde ich bei Änderungen die ich grad zurzeit mache echt lästig.

Ist das nicht eher der Regelfall als FTUI-spezifisch? Nach Änderungen muss doch die komplette Seite (oder bei einzelnen Widgets die entsprechende page) neugeladen werden (im FF mit [Shift]+[F5]).

TabletUI ist sehr JavaScript-lastig und erfordert dementsprechend auch Resourcen auf der Client-Seite. Ein  Einsteiger/Mittelklasse-Tablet, was dann ggfs. auch nicht mehr topaktuell ist, kann da schon an die Grenzen kommen.

Es hängt zudem auch von der Performance des Browsers ab - und wie oft FTUI Daten von FHEM holt.

Ich habe Ladezeiten von ~10s bei Erstbeladung, und ich sehe dann auch schön, wie die Widgets eines nach dem anderen geladen und mit Daten befüllt werden. Wenn FTUI geladen ist, läuft es recht flüssig.
Hinzu kommt, dass initial recht viel Daten vom FHEM-Server abgeholt und verarbeitet werden muss.

Nicht vergessen: FTUI arbeitet mit viel JS auf Client-Ebene - und es ist ein recht einfach zu nutzendes Framework, welches out-of-the-box recht gut funktioniert.

Es scheint auch so, als würde setstate an einer neuen FTUI Version arbeiten.

[moonsorrox]

Ist das nicht eher der Regelfall als FTUI-spezifisch? Nach Änderungen muss doch die komplette Seite (oder bei einzelnen Widgets die entsprechende page) neugeladen werden (im FF mit [Shift]+[F5]).

das mache ich sowieso jedesmal, hilf aber oft leider auch nicht