erste beta - fronthem, smartVISU (closed, Bitte die Anschlussthreads benutzen)

[marvin78]

@marvin: ich finde jetzt Deine 60-70 GADs nicht soviel. Entweder Deine Erwartungshaltung unterscheidet sich oder da ist noch was anderes. Bitte sei doch so nett und mach echt mal Messungen, an die widget Farbe etc bist Du ja auch rangegangen. Oder anders: schau doch mal ob sich ein jungräuliches sv dir gleich verhält. Dazu könntest Du in einen jungfräulichen Verzeichnis (wichtig ohne eigene visu.js und so) widgets (GAD) mit den Namen internal.0, internal.1  usw anlegen - fronthem bedient die automatisch ohne das Du was im Editor einstellen musst.

Meine Erwartungshaltung ist sicher nicht zu hoch. 10-15 Sekunden für eine normale Seite ist einfach zu viel. 60-70 Gads sind auch nur im Menü. Davon hat man schnell mal 10 im DOM, wenn der Cache an ist. Den Rest habe ich tatsächlich probiert. Klar bringt es was, nur wenige unterschiedliche Widgets zu haben. Das kann nicht die Lösung des Problems sein. Ein Workaround auf dem Handy ist tatsächlich auf die full.html zu setzen und das Menü weg zu lassen. Dann fluppt es ganz ordentlich. Das zeigt mit, das es tatsächlich die vielen Elemente im DOM sind, die das Problem machen. Ich denke einfach, dass ich schon ein sehr umfangreiches System habe. Insgesamt bin ich bei fast 600 gads (Widgets der untschiedlichen Art).

@HCS: Liegt dem Video dein experimenteller Treiber zu Grunde? Ist das alles das gleiche Widget? Bei mir läuft sowas im Vergleich dazu in extremer Zeitlupe ab. Es aktualisiert sich ein gad pro viertel Sekunde. Wenn es bei mir halb so schnell wäre, wäre ich extrem zufrieden.

Den Treiber werde ich gerne mal testen. Dazu komme ich frühestens morgen.

[herrmannj]

jetzt beiss Dich doch nicht so am DOM fest - mach mal bitte eine Messung - alles andere bringt doch nix.

vg
jörg

[HCS]

Das Problem ist, dass, was immer man tun möchte, man alle Widgets ändern müsste.

Hier steckt das Problem:
$(document).delegate('[data-widget="basic.float"]', {

Beispiel basic.float:

Code Auswählen Erweitern

// ----- basic.float ----------------------------------------------------------
$(document).delegate('[data-widget="basic.float"]', {
'update': function (event, response) {
if ($(this).attr('data-unit') != '') {
$('#' + this.id).html(parseFloat(response).transUnit($(this).attr('data-unit')));
}
else {
$('#' + this.id).html(parseFloat(response).transFloat());
}

}
});

[bgewehr]

Na und? Sind ja keine 100?!

[herrmannj]

ich schau auch grad drauf - vielleicht gibt es Alternativen. Wenn wir das machen dann geht der updatepfad flöten, dann können wir echt gleich alles forken ...

wollen wir das wirklich ? Eigentlich spricht nichts dagegen, aber dann haben wir auch die ganze Arbeit an der Backe.  .... (unsicher)

[marvin78]

@hermannj: Ich weiß ehrlich gesagt nicht wie?! Am Ende ist entscheidend, was am Bildschirm geschieht und da aktualisieren sich die gads sehr langsam und vor allem auch stockend (mit teilweise sekundenlangen Pausen) - Vielleicht sollte ich mal ein Video zeigen.

@HCS: Ich habe nichts dagegen, die Widgets zu ändern. Ich habe schon überlegt, eine Art Superwidget zu bauen und die Art über ein weiteres Attribut zu steuern, um nur noch wenige Arten Widgets zu haben. Einen Versuch wäre es Wert.

Ich komme nochmal zu den Fragen zurück:

@HCS: Liegt dem Video dein experimenteller Treiber zu Grunde? Ist das alles das gleiche Widget? Bei mir läuft sowas im Vergleich dazu in extremer Zeitlupe ab. Es aktualisiert sich ein gad pro viertel Sekunde. Wenn es bei mir halb so schnell wäre, wäre ich extrem zufrieden.

Den Treiber werde ich gerne mal testen. Dazu komme ich frühestens morgen.

[bgewehr]

Halb so wild, ist doch nur die widget.js, oder?

[HCS]

jetzt beiss Dich doch nicht so am DOM fest - mach mal bitte eine Messung - alles andere bringt doch nix.

Ich habe gemessen, reichlich und was ich weiter oben beschrieben habe, ist das Ergebnis der Messungen.
Aufgrund von diesem Ergebnis habe ich den Treiber experimentell so geändert, dass er die beiden Sorten widgets ohne events aktualisiert, mit dem Ergebnis, das im Video zu sehen ist.
Die Zeit, bis SV wieder aus dem trigger-Aufruf rauskommt, liegt auf dem Test-Tablet zw. 60 und 100ms. Meine Aktualisierung ohne events braucht 2 bis 3ms.

@HCS: Liegt dem Video dein experimenteller Treiber zu Grunde? Ist das alles das gleiche Widget? Bei mir läuft sowas im Vergleich dazu in extremer Zeitlupe ab. Es aktualisiert sich ein gad pro viertel Sekunde. Wenn es bei mir halb so schnell wäre, wäre ich extrem zufrieden.
Den Treiber werde ich gerne mal testen. Dazu komme ich frühestens morgen.

Ja, das war mit dem experimentellen Treiber. Original ist deutlich langsamer.

[herrmannj]

@HCS

Ich habe gemessen, reichlich und was ich weiter oben beschrieben habe, ist das Ergebnis der Messungen.

sorry, das war für marvin.  nicht für Dich - wir haben ja gemessen  - Du ganz viel

[herrmannj]

Halb so wild, ist doch nur die widget.js, oder?

ja, hast schon Recht. Muss man aber aufpassen. Charmant ist ja das sv einfach "da ist". Auf der anderen Seite: mandanten: ergänzt. driver mit reconnect: ergänzt. Einige widgets: ergänzt. Und pass mal auf, bei den plots kommt auch das eine oder andere.... soweit isses also echt nich ... Man muss nur echt aufpassen das man nicht im Eifer anfängt irgendwas zu verschlimmbessern. Was denkt Ihr ? (Bernds Antwort kenn ich  )

vg
jörg

[bgewehr]

Anfangen!

[cruser1800]

Für ein bisschen Geschwindigkeit würde ich gern das eine oder andere Ändern! 

[HCS]

Die Idee, die wirklich hilft, selbst wenn man die Widgets ändern wollte, fehlt mir aber auch noch.

Ich schreibe da gerade im Treiber Stück für Stück ein SV. Oh, gerade den post gesehen, wärend ich schreibe, unsere Gedanken ähneln sich.
Ich muss mal in Ruhe nachdenken, was die Optionen sind.
Könnte vielleich noch jemand mal den experimentellen Treiber probieren, was er an der Geschwindigkeit ändert, verglichen mit dem Domotiga.

Charts: das habe ich im Treiber bereits weitgehend implementiert, fast komplett an SV vorbei, weil ich es nicht später Stück für Stück dann doch rausziehen wollte.
Nur so waren die Anforderungen, die ich tausend posts weiter oben beschrieben habe, machbar.

[HCS]

Mann, das Forum braucht länger zum Absenden eines Beitrags als SV für 50 GADs 

Was auch immer wir nun machen, dass sollte gut und in Ruhe überlegt sein, weil es weitreichende Konsequenzen haben kann.

[herrmannj]

yepp. seh ich auch so. Mehr speed wäre schön - am besten mit Plan


<klugscheiss>
Plan, der: gedankliche Vorwegnahme zukünftigen Handelns
</klugscheiss>