nicht angemeldet
Rechenintensives Script im Hintergrund ausführen
Struppi
JürgenBIch habe ein kleines Problem:
ich habe ein recht rechenintensives JS und habe es mit <body onload= ... > eingebunden. Nun habe ich das Problem, das der Browser erst mal nicht mehr regiert (ich kann nicht scrollen oder anklicken). Gibt es ne Möglichkeit, die Seite erst vollständig rendern zu lassen und danach erst das JS im Hintergrund ausführen zu lassen?
grüße
Gonza
-
hi,
ich habe ein recht rechenintensives JS und habe es mit <body onload= ... > eingebunden. Nun habe ich das Problem, das der Browser erst mal nicht mehr regiert (ich kann nicht scrollen oder anklicken). Gibt es ne Möglichkeit, die Seite erst vollständig rendern zu lassen und danach erst das JS im Hintergrund ausführen zu lassen?
Nein, so etwas wie eine "Hintergrundverarbeitung" gibt es m.W. in Javascript nicht.
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; }-
Hallo,
was genau tust Du denn da mit Deinem Script?
Vielleicht gibt es ja zunächst erst einmal Möglichkeiten, die Programmlogik zu ändern.
Ansonsten - siehe wahsaga.Ciao,
Andreas--
"Das Corporate Design für das Internet sieht eine Reihe von Grafikelementen vor, die die Optik der Webseite visuell und funktionell beeinflussen." - (Zitat aus dem "Styleguide Corporate Design" eines großen Konzerns...)-
Hallo,
was genau tust Du denn da mit Deinem Script?
Vielleicht gibt es ja zunächst erst einmal Möglichkeiten, die Programmlogik zu ändern.
Ansonsten - siehe wahsaga.Ciao,
AndreasHallo,
das Script durchsucht den innerHTML Text nach Schlüsselwörtern und versieht sie mit einem Highlight (farbliche Ändernung). Der Rechenintensieve Teil dürfte die Suchfunktion sein.
function searchTerms(searchText, highlightStartTag, highlightEndTag)
{
searchArray = searchText.split(" ");var bodyText = document.body.innerHTML;
for (var i = 0; i < searchArray.length; i++) {
bodyText = doHighlight(bodyText, searchArray[i], highlightStartTag, highlightEndTag);
}
document.body.innerHTML = bodyText;
return true;
}searchText ist eine Kette von Wörtern übergeben, die mit einem Leerzeichen getrennt sind. Ich glaube kaum, das man das schneller hin bekommt. Zur Not versuche ichs mit Jürgens Idee.
grüße
Gonza-
Hallo,
searchText ist eine Kette von Wörtern übergeben, die mit einem Leerzeichen getrennt sind. Ich glaube kaum, das man das schneller hin bekommt. Zur Not versuche ichs mit Jürgens Idee.
Ja, so etwas ist immer verzwickt.
Vielleicht kannst Du aber doch etwas ändern. Anstatt mit der innerHTML-Eigenschaft des BODY-Elements zu arbeiten, könntest Du gezielter auf die Inhalte zugreifen, auf die es ankommt. Das wäre vorteilhaft, da innerhalb von BODY sicher jede Menge Markup vorkommt, das für Dein Highlighting gar nicht relevant ist.
Du könntest beispielsweise nur innerhalb bestimmter Elemente suchen, also etwa in allen P-, LI-, SPAN- und A-Elementen oder so (Stichwort getElementsByTagName()).
Und vielleicht kannst Du auch unterhalb der Ebene des BODY anfangen - vielleicht bei einem content-DIV, falls es so etwas gibt.Ich kann Dir jetzt aber leider nicht versichern, daß das hilft. Ich selbst hatte einmal ein ähnliches Problem, bei dem ich allerdings mit sehr komplexen regulären Ausdrücken gearbeitet habe - das Ausführen dieses Javascripts hat dann bei umfangreichen Seiten über eine Minute gedauert. Habe das Script dann weggeschmissen und einen völlig anderen Ansatz (serverseitig) gewählt.
Ciao,
Andreas--
"Das Corporate Design für das Internet sieht eine Reihe von Grafikelementen vor, die die Optik der Webseite visuell und funktionell beeinflussen." - (Zitat aus dem "Styleguide Corporate Design" eines großen Konzerns...)-
Nein, ist leider alles nicht möglich.
Den Content bekomme dynamisch geliefert, ich muss also direkt unter dem BODY anfangen. Serverseitig wäre einfacher und komfortabler, aber leider nicht möglich.
Trotzdem danke für den Versuch. :)
grüße
Gonza
-
-
das Script durchsucht den innerHTML Text nach Schlüsselwörtern und versieht sie mit einem Highlight (farbliche Ändernung). Der Rechenintensieve Teil dürfte die Suchfunktion sein.
function searchTerms(searchText, highlightStartTag, highlightEndTag)
{
searchArray = searchText.split(" ");var bodyText = document.body.innerHTML;
for (var i = 0; i < searchArray.length; i++) {
bodyText = doHighlight(bodyText, searchArray[i], highlightStartTag, highlightEndTag);
}
document.body.innerHTML = bodyText;Ich glaube eher das hier der Rechenintensive Teil ist. du baust die Seite ja nochmal komplett neu auf. Warum? kann deine doHighlight() Funktion keine Knoten einfügen?
Übrigens gibt es da auch ein Skript, das google Suchwörter markiert, keine Ahnung wie das heißt aber das ist auch JS. Und funktioniert ohne Verzögerung. Musste mal nach suchen.
Struppi.
-
-
-
-
Hallo Gonza,
du könntest noch die Ausführung des Scripts nach den onload um eine angemessene Zeit verzögern, damit der Browser fertig rendern kann. Du könntest auch die Hauptschleife des rechenintensiven Scriptes durch ein setTimeout-Konstrukt realisieren es so nach jeder "Runde" eine kleine Pause einlegen lassen, um dem Browser Zeit für Scrollen, etc. zu geben. Ich habe das aber nie selbst getestet.
Gruß, Jürgen
-
Hallo Jürgen,
ich hatte schon eine ähnliche Idee, aber irgendwie will es nicht funktionieren. Vielleicht kannst du mit ja helfen:
for (var i = 0; i < searchArray.length; i++) {
k = 0;
window.setTimeout("bodyText = doHighlight(bodyText, searchArray[i], highlightStartTag, highlightEndTag)", 1000);
if (j >= maxItems) {break;}
}Das war mein Ansatz, aber der Teil im setTimeout Block scheint einfach übergangen zu werden. Hast du ne Idee, woran es liegt?
grüße
Gonza-
Hallo Gonza,
for (var i = 0; i < searchArray.length; i++) {
k = 0;
window.setTimeout("bodyText = doHighlight(bodyText, searchArray[i], highlightStartTag, highlightEndTag)", 1000);
if (j >= maxItems) {break;}
}zwei Probleme:
1. Wenn du setTimeout innerhalb einer Funktion aufrufst und lokale Variablen verwendest, ist die Funktion beendet, wenn die verzögerte Operation läuft und die Variablen existieren nicht mehr.
Mögliche Abhilfe: globale Variablen.2. Im Codeschnippsel oben setzt du so schnell wie möglich die Timeouts mit gleicher Verzögerungszeit ab. Sie werden dann nach Ablauf der Verzögerungszeit auch so schnell wie möglich abgearbeitet.
Abhilfe: Führe das Ersetzen in einer Funktion aus, die auch den Zähler (global) erhöht und wenn er noch nicht am Ende ist, ruft die Funktion sich selbst per setTimeout auf.
Also etwa so:i=0;
function tuwas() {
i++;
if (i<10) window.setTimeout("tuwas()",1000) ;
alert(i);
}<body onload="tuwas()">
Gruß, Jürgen
-
-
Hallo JürgenB.
du könntest noch die Ausführung des Scripts nach den onload um eine angemessene Zeit verzögern, damit der Browser fertig rendern kann.
Warum? So bald onload feuert, ist das Dokument bereits vollständig geladen.
Einen schönen Mittwoch noch.
Gruß, Ashura
-
Hallo Ashura,
Warum? So bald onload feuert, ist das Dokument bereits vollständig geladen.
geladen. Aber ich bin nicht sicher, ob auch in allen Browsern fertig gerendert. Ich habe Gonza so verstanden. Bei dynamisch erstellten Seiten habe ich die Erfahrung gemacht, dass bei CPU-lastigen Scripten erst am Ende gerendert wird. (Ausnahme: Opera)
Und schließlich heißt es ja auch onload= und nicht onfertiggerendert=. :)Gruß, Jürgen
-
Hallo JürgenB.
Warum? So bald onload feuert, ist das Dokument bereits vollständig geladen.
geladen. Aber ich bin nicht sicher, ob auch in allen Browsern fertig gerendert.
Der Eventhandler onload impliziert meines Wissens das Vorhandensein sämtlicher statischer Elementknoten im Dokumentenbaum.
Auch wenn einzelne Ressourcen noch nicht gänzlich geladen sind, sollte dies das Abarbeiten von Scripts nicht beeinflussen.Bei dynamisch erstellten Seiten habe ich die Erfahrung gemacht, dass bei CPU-lastigen Scripten erst am Ende gerendert wird. (Ausnahme: Opera)
Solch Ressourcen verschlingenden Skripte habe ich bisher erlebt noch selbst geschrieben, ich kann dies daher nicht nachvollziehen.
Einen schönen Mittwoch noch.
Gruß, Ashura
-
Hallo Ashura,
Solch Ressourcen verschlingenden Skripte habe ich bisher erlebt noch selbst geschrieben, ich kann dies daher nicht nachvollziehen.
hier die "Killerapplikation":
http://www.j-berkemeier.de/LogistischeAbbildung.html
Eine 6 GHz CPU wird empfohlen.
Interessant ist ein Vergleich zwischen Firefox, Opera und IE.Gruß, Jürgen
-
Hallo JürgenB.
hier die "Killerapplikation":
http://www.j-berkemeier.de/LogistischeAbbildung.html
Eine 6 GHz CPU wird empfohlen.
Oder eine andere Programmiersprache.
Interessant ist ein Vergleich zwischen Firefox, Opera und IE.
Wenn Opera (9 TP1) beim „Plotten“ etwas tun würde und nicht zusätzlich diesen kleinen Anzeigefehler hätte, könnte ich seine Performance mit den Ruckeleinlagen von Fx und IE vergleichen.
Ist für dich sicher weniger interessant, für die Opera-Entwickler dagegen schon eher.
Einen schönen Mittwoch noch.
Gruß, Ashura
-
Hallo Ashura,
Oder eine andere Programmiersprache.
stimmt. Diese Seite hat mir die Grenzen von JS sehr deutlich gezeigt.
Wenn Opera (9 TP1) beim „Plotten“ etwas tun würde und nicht zusätzlich diesen kleinen Anzeigefehler hätte, könnte ich seine Performance mit den Ruckeleinlagen von Fx und IE vergleichen.
Ruckeln sie bei dir? Bei mir ist nur einige Zeit Ruhe und dann kommt der Plot. Der Firefox braucht außerden nach dem Plotten zum Scrollen mehrere 10 Sekunden. Übrigen, Opera (7 u. 8) zeigt den Plotvorgang Punkt für Punkt an. Und das auch noch recht zügig.
Ist für dich sicher weniger interessant, für die Opera-Entwickler dagegen schon eher.
Schon, wenn das im endgültigen 9er immer noch so ist.
Gruß, Jürgen
-
Hallo JürgenB.
Ruckeln sie bei dir?
Sowohl IE als auch Fx ruckeln sehr stark nach Plotten und folgendem Aufziehen eines Rechtecks. Das Plotten selbst geht relativ fix von Statten.
Übrigen, Opera (7 u. 8) zeigt den Plotvorgang Punkt für Punkt an. Und das auch noch recht zügig.
Umso mehr verwundert mich, dass sich in der 9TP1 gar nichts tut.
Ist für dich sicher weniger interessant, für die Opera-Entwickler dagegen schon eher.
Schon, wenn das im endgültigen 9er immer noch so ist.
Das bezweifle ich. Einen Bugreport habe ich bereits abgesetzt.
Einen schönen Mittwoch noch.
Gruß, Ashura
-
Hallo Ashura,
Sowohl IE als auch Fx ruckeln sehr stark nach Plotten und folgendem Aufziehen eines Rechtecks. Das Plotten selbst geht relativ fix von Statten.
ach so. So kenne ich das auch. IE und auch Firefox tun sich schon sehr schwer damit, die mehreren Tausend absolut positionierten <span>s zu erstellen und dann zu verwalten. Aber wenn man es nicht übertreibt, lassen sich so schon schöne Dinge machen.
Gruß, Jürgen
-
Hallo JürgenB.
Aber wenn man es nicht übertreibt, lassen sich so schon schöne Dinge machen.
In der Tat. (Quelle)
Einen schönen Mittwoch noch.
Gruß, Ashura
-
Hallo Ashura,
In der Tat. (Quelle)
auch wenn ich es nicht testen konnte, lt. Beschreibung scheint das was gutes zu sein. Vor allem, weil keine Plugins benötigt werden. Ich vermute aber, dass es mehrere Jahre dauert, bis mehr als die Hälfte aller Besucher einen Canvas-tauglichen Browser haben. Und so lange werde ich bei meinen Spielereien noch weiter <span>s über den Bildschirm schieben müssen.
Gruß, Jürgen
-
Hallo JürgenB.
In der Tat. (Quelle)
auch wenn ich es nicht testen konnte,
Hast du keinen Opera 9TP1 / Fx 1.5 zur Verfügung?
lt. Beschreibung scheint das was gutes zu sein. Vor allem, weil keine Plugins benötigt werden.
Absolut richtig. Und eine CPU-Auslastung ist praktisch nicht bemerkbar.
Ich vermute aber, dass es mehrere Jahre dauert, bis mehr als die Hälfte aller Besucher einen Canvas-tauglichen Browser haben. Und so lange werde ich bei meinen Spielereien noch weiter <span>s über den Bildschirm schieben müssen.
Wohl oder übel ja.
Techniker haben es schon schwer im Web; sie sind ihrer Zeit immer weit voraus...Einen schönen Donnerstag noch.
Gruß, Ashura
-
-
-
-
-
-
-
-
-
-
-
