veränderte Formulardaten zwischen Divs kopieren
j0Shi
- javascript
Moin!
Folgendes Problem:
Auf meiner Webseite gibt es die Möglichkeit bei verschiedenen Formularen Voreinstellungen auszuwählen, um die Eingabe zu verkürzen.
Wählt man also z.B. die Voreinstellung A für das Formular, dann legt Javascript los:
document.getElementById('erstesTextfeld').value = 'eins';
document.getElementById('zweitesTextfeld').value = 'zwei';
document.getElementById('ersteCheckbox').checked = true;
usw. ...
Das Problem ist: Man kann der Veränderung quasi zuschauen. Da bis zu 30 Formularfelder verändert werden, geht das ganze relativ langsam und daher für das Auge sichtbar von statten. Also habe ich mir überlegt, dass es sinnvoller wäre wenn man eine Art Ladegrafik vorschaltet und dann erst das komplett veränderte Formular wieder sichtbar macht.
Aber auch hier kommt es zu einem visuellen Problem:
Das Formular befindet sich in einer Tabelle. Ich stelle das Div, welches das Formular enthält auf "visibility:none", füge dann in die Tabelle ein "LadeDiv" ein mit der Ladegrafik, verändere die Formulardaten, lösche das Div mit der Ladegrafik und stelle das Forlumardiv wieder auf "visibility:visible." Da hier die Befehle aber natürlich wieder hintereinander ablaufen, wird das Ladediv gelöscht und die Tabellenspalte kurzfristig "eingeklappt", da ja kein Inhalt vorhanden ist. Danach klappt sie auf mit den veränderten Formulardaten. Das hört sich nicht wirklich schlimm an, aber dieses ganz kurze "zu- und aufklappen" sieht grausig aus.
Also nächste Möglichkeit probiert ...
Ich dachte mir dass es zu diesem Effekt nicht kommen sollte, wenn ich nicht mit der Visibility arbeite, sondern den Inhalt des Divs direkt verändere. Also nach dem Muster:
Ein verstecktes Div erzeugen, Formular dorthin kopieren, dann in das Original-Div Ladegrafik einfügen, Formular verändern und das Forumlar wieder in das Original-Div kopieren und das versteckte löschen.
Das funktioniert visuell auch so wie ichs will. Es wechselt sehr "harmonisch" zwischen Ladegrafik und Formular.
Jetzt ist allerdings das Problem, dass ich die veränderten Formulardaten nicht kopiert bekomme zwischen den beiden Divs. Die Hinfahrt ist ja einfach:
HiddenDiv.innerHTML = FormularDiv.innerHTML;
FormularDiv.innerHTML = 'ladegrafik.gif';
//Formularfelder verändern
Wenn ich jetzt in der Form von FormularDiv.innerHTML = HiddenDiv.innerHTML zurückkopieren will, funktioniert das Ganze natürlich so nicht, weil ich den HTML-Code ja kein Stück verändere. Also bekomme ich das Original-Formular und nicht die veränderte Version.
Da das ganze über Ajax läuft, weil ich die Voreinstellungen aus einer Datenbank holen muss, wäre es recht einfach die Geschichte auf php-Ebene zu lösen, indem ich einfach das Forumlartemplate lade, entsprechend verändere und ausgebe. Aufgrund der Funktionalität bin ich aber an einer reinen Javascript-Lösung interessiert (falls das überhaupt geht).
Hat da jemand eine Idee?
Grüße,
j0Shi
Hi,
Das Problem ist: Man kann der Veränderung quasi zuschauen.
dafür sehe ich mehrere Möglichkeiten:
a) Du arbeitest mit einem C-64.
b) Du gehörst einer Spezies an, die mehrere Hunderttausend bis Millionen Bilder pro Sekunde wahrnimmt.
c) Dein Browser ist kaputt.
d) Du verschweigst uns relevante Vorgänge, die auf der Seite bzw. dessen Umfeld stattfinden, ob im direkten Zusammenhang mit Deinem Vorhaben oder nicht.
Die Lösungen lauten:
a) Nutze etwas modernere Systeme.
b) Lasse Dich operieren, so dass Deine Wahrnehmung reduziert wird.
c) Repariere den Browser.
d) Erzähle uns Details. Ein Link zur Problemseite könnte ebenfalls hilfreich sein.
Cheatah
a) Duron 1400, 512 MB. Meine "Entwicklungsumgebung" (Office-PC) gibt leider nicht mehr her.
b) Nein, es hört bei mir ganz menschlich bei 25 fps (ruckelfrei) auf
c) Eher nicht
d) auch nicht
Zwischen den Zeilen lese ich allerdings, dass das ganze wohl ein Performance-Problem meines Rechners darstellt und auf einem modernen Webserver so nicht auftreten sollte. Das würde mir auch reichen. Trotzdem wäre ich rein interessehalber weiterhin an einer Lösung interessiert, da mehr Speed zwar das Problem beseitigt, nicht aber die Ursache der sequientellen Abarbeitung.
Gruß,
j0Shi
Mahlzeit j0Shi,
a) Duron 1400, 512 MB. Meine "Entwicklungsumgebung" (Office-PC) gibt leider nicht mehr her.
Macht ja nichts, ist doch vollkommen ausreichend. Wenn man einen richtigen Browser benutzt. Und wenn die HTML-Datei nicht gigantisch groß, stattdessen aber valide ist. Und wenn der Javascript-Code performanceschonend arbeitet. Über alles hast Du aber noch kein Sterbenswörtchen verloren.
Darf ich Dich daher nochmal an Cheatahs Punkt d) hinweisen?
d) Du verschweigst uns relevante Vorgänge, die auf der Seite bzw. dessen Umfeld stattfinden, ob im direkten Zusammenhang mit Deinem Vorhaben oder nicht.
d) Erzähle uns Details. Ein Link zur Problemseite könnte ebenfalls hilfreich sein.
d) auch nicht
Denn Deine Antwort darauf ist - gelinde gesagt - ein Witz. Wenn Du keine Hilfe WILLST, dann ist das OK, dann brauchst Du keine Details zu nennen. Aber von Deinen Lesern zu erwarten, dass sie eine funktionsfähige Glaskugel besitzen und diese jetzt extra für Dich hervorkramen und aktivieren, ist doch ziemlich frech.
Zwischen den Zeilen lese ich allerdings, dass das ganze wohl ein Performance-Problem meines Rechners darstellt und auf einem modernen Webserver so nicht auftreten sollte.
Mit dem Webserver hat das absolut gar nichts zu tun. War das ein Versehen, oder sind Dir die Zusammenhänge und Begrifflichkeiten nicht ganz klar?
Das würde mir auch reichen. Trotzdem wäre ich rein interessehalber weiterhin an einer Lösung interessiert, da mehr Speed zwar das Problem beseitigt, nicht aber die Ursache der sequientellen Abarbeitung.
Und wir sind weiterhin an näheren Informationen interessiert, da ohne sie nur ein blindes Herumstochern im Nebel möglich ist. Im Gegensatz zu Deinen Annahmen bzw. Behauptungen kann nämlich sehr wohl Größe, Art, Umfang, Aufbau und Validität der HTML-Seite und Komplexität des enthaltenen Javascript-Codes (mit-)ursächlich für Dein Problem sein.
MfG,
EKKi
Huhu,
erstmal danke für die bisherige Hilfe & Tips.
Aber ich glaube wir steuern hier in eine falsche Richtung. Mal vorweg: Der HTML-Code ist nach 4.01T valide und die erzeugte HTML-Datei 65 KB groß. Um die Fehlerseite jetzt so online zu präsentieren, müsste ich das komplette Projekt hochladen, MySQL-Datenbank einrichten usw. Das würde jetzt den Rahmen sprengen. Wenn es wirklich nicht anders geht, muss ich mich halt noch einmal melden, wenn das ganze online zu sehen ist (dauert) :(
Versuche jetzt aber hier nochmal genau die Funktionsweise zu erläutern:
Wir haben also das Formular und ein Select-Feld, in dem die zur Verfügung stehenden Voreinstellungen ausgewählt werden.
Select-Feld:
onchange="javascript:xajax_intern_xwars_settings_galasearch_change_search(this.options[this.selectedIndex].value)"
Xajax-Funktion:
function intern_xwars_settings_galasearch_change_search($searchID) {
global $db_zugriff;
$response = new xajaxResponse();
$xajaxControl = new xajax_control($response);
$xajaxControl->clear_inputerrors("form_intern_xwars_settings_galasearch");
if (!$xajaxControl->control_user_searches($searchID, true)) {
$response->addAssign("div_intern_main_statusmsg", "innerHTML", get_status_msg("common", "error"));
$response->addScript("document.getElementsByName('drop_intern_xwars_settings_galasearch_list')[0].options[0].selected = true");
$response->addScript("document.getElementsByName('drop_intern_xwars_settings_galasearch_editoptions')[0].options[1].selected = true");
$response->addScript("document.getElementById('form_intern_xwars_settings_galasearch').reset()");
return intern_set_created_time($response);
}
if ($searchID != "") {
$db_daten = $db_zugriff->query_first("SELECT `values`, `name` FROM ".xwtable_usersearch." WHERE id = '".$searchID."'");
$response->addScript("javascript:xwars_intern_xwars_settings_galasearch_fill_values('".mysql_real_escape_string($db_daten['values'])."')");
$response->addScript("document.getElementsByName('drop_intern_xwars_settings_galasearch_editoptions')[0].options[0].selected = true");
$response->addScript("document.getElementsByName('t_intern_xwars_settings_galasearch_new')[0].value = '".mysql_real_escape_string($db_daten['name'])."'");
} else {
$response->addScript("document.getElementById('form_intern_xwars_settings_galasearch').reset()");
}
return intern_set_created_time($response);
}
Die wichtige Zeile:
$response->addScript("javascript:xwars_intern_xwars_settings_galasearch_fill_values('".mysql_real_escape_string($db_daten['values'])."')");
Die aufgerufene Funktion:
function xwars_intern_xwars_settings_galasearch_fill_values(form_values) {
var val_arr = form_values.split('###|||###');
document.getElementsByName('t_intern_xwars_settings_galasearch_playername')[0].value = val_arr[0];
if (val_arr[1] == 'on') document.getElementsByName('check_intern_xwars_settings_galasearch_show_unsettled')[0].checked = true;
else document.getElementsByName('check_intern_xwars_settings_galasearch_show_unsettled')[0].checked = false;
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].options[i].value == val_arr[2]) document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].options[i].selected = true;
}
document.getElementsByName('t_intern_xwars_settings_galasearch_ally')[0].value = val_arr[3];
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_gala')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_gala')[0].options[i].value == val_arr[4]) document.getElementsByName('drop_intern_xwars_settings_galasearch_gala')[0].options[i].selected = true;
}
document.getElementsByName('t_intern_xwars_settings_galasearch_system')[0].value = val_arr[5];
document.getElementsByName('t_intern_xwars_settings_galasearch_planet')[0].value = val_arr[6];
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_gala2')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_gala2')[0].options[i].value == val_arr[7]) document.getElementsByName('drop_intern_xwars_settings_galasearch_gala2')[0].options[i].selected = true;
}
document.getElementsByName('t_intern_xwars_settings_galasearch_system2')[0].value = val_arr[8];
document.getElementsByName('t_intern_xwars_settings_galasearch_planet2')[0].value = val_arr[9];
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_planet_type')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_planet_type')[0].options[i].value == val_arr[10]) document.getElementsByName('drop_intern_xwars_settings_galasearch_planet_type')[0].options[i].selected = true;
}
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_research')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_research')[0].options[i].value == val_arr[11]) document.getElementsByName('drop_intern_xwars_settings_galasearch_research')[0].options[i].selected = true;
}
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_building')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_building')[0].options[i].value == val_arr[12]) document.getElementsByName('drop_intern_xwars_settings_galasearch_building')[0].options[i].selected = true;
}
document.getElementsByName('t_intern_xwars_settings_galasearch_research_min')[0].value = val_arr[13];
document.getElementsByName('t_intern_xwars_settings_galasearch_research_max')[0].value = val_arr[14];
document.getElementsByName('t_intern_xwars_settings_galasearch_building_min')[0].value = val_arr[15];
document.getElementsByName('t_intern_xwars_settings_galasearch_building_max')[0].value = val_arr[16];
document.getElementsByName('t_intern_xwars_settings_galasearch_numresults')[0].value = val_arr[17];
if (val_arr[18] == 'on') document.getElementsByName('check_intern_xwars_settings_galasearch_unsettled_planet')[0].checked = true;
else document.getElementsByName('check_intern_xwars_settings_galasearch_unsettled_planet')[0].checked = false;
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_sort')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_sort')[0].options[i].value == val_arr[19]) document.getElementsByName('drop_intern_xwars_settings_galasearch_sort')[0].options[i].selected = true;
}
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_sortorder')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_sortorder')[0].options[i].value == val_arr[20]) document.getElementsByName('drop_intern_xwars_settings_galasearch_sortorder')[0].options[i].selected = true;
}
}
@Cheatah:
Das mit der sequentiellen Abarbeitung ist mir schon klar. Ich meinte in diesem Zusammenhang aber ja einen Lösungsvorschlag zu diesem Problem:
FormularDiv verstecken
LadeDiv erzeugen & anzeigen
FormularDiv verändern
LadeDiv löschen
FormularDiv anzeigen
Da kommt es bei mir eben zu den o.g. "rucklern"
Besser wäre es:
StoreDiv erzeugen
Inhalt des FormularDivs in StoreDiv kopieren (geht mit innerHTML)
Mit Ladegrafik Inhalt des FormularDivs überschreiben (geht mit innerHTML)
Formular im StoreDiv verändern
Inhalt des FormularDivs mit den veränderten Formulardaten aus dem StoreDiv überschreiben (geht nicht mit innerHTML)
StoreDiv löschen
D.h. es wird von der Ladegrafik das Formular überschrieben und umgekehrt. Dabei kommt es zu keinen "rucklern", allerdings habe ich keine Möglichkeit das veränderte Formular wie o.g. zu kopieren, mit innerHTML funktioniert es (logischerweise) nicht.
Ich bin natürlich für jeden Performance - Tip dankbar, allerdings suche ich in erster Linie weiterhin eine Möglichkeit, dieses "überschreiben" mit den veränderten Formulardaten zu realisieren.
Gruß,
j0Shi
Mahlzeit j0Shi,
Mal vorweg: Der HTML-Code ist nach 4.01T valide und die erzeugte HTML-Datei 65 KB groß. Um die Fehlerseite jetzt so online zu präsentieren, müsste ich das komplette Projekt hochladen, MySQL-Datenbank einrichten usw. Das würde jetzt den Rahmen sprengen.
Nein, müsstest Du nicht. Wenn es ein rein clientseitiges Problem wäre, reichte es, wenn Du z.B. die Seite, die so langsam arbeitet, als reines pures HTML mal auf Deinem Rechner speicherst und dann irgendwo hochlädst (ggf. mit den externen Ressourcen wie Bildern usw.).
Select-Feld:
onchange="javascript:xajax_intern_xwars_settings_galasearch_change_search(this.options[this.selectedIndex].value)"
Was genau soll das Protokoll "javascript:" sein? Lass diese Angabe einfach weg - sie ist irreführend, sinnlos und falsch.
> Xajax-Funktion:
> ~~~php
> function intern_xwars_settings_galasearch_change_search($searchID) {
Hm, Moment. Das hier ist jetzt PHP-Code? Ich dachte, Es geht um Javascript? Was hat PHP-Code bei einem clientseitigen (Javascript-)Problem verloren?
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].options[i].value == val_arr[2]) document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].options[i].selected = true;
}
Du weißt schon, dass der Javascript-Parser hier JEDESMAL das GESAMTE Dokument durchsuchen, alle Elemente eines Namens finden, in ein Array packen, dann auf das erste Element zugreifen, anschließend durch alle Optionen des Elements laufen, diese wiederum in ein Array packen und dann mittels der aktuellen Zählvariable dort das richtige herauspicken muss?
Und bei allen anderen ähnlichen Konstruktionen genauso.
Performance ist was anderes ...
Ich bin natürlich für jeden Performance - Tip dankbar, allerdings suche ich in erster Linie weiterhin eine Möglichkeit, dieses "überschreiben" mit den veränderten Formulardaten zu realisieren.
Das brauchst Du nicht, wenn Du Dein Skript auf Performance optimieren würdest. Und zwar richtig.
Eine kleine persönliche Anmerkung noch zum Schluss:
Das ganze sieht mir wie der 37392721. Klon eines Browsergames aus. Für mich persönlich stellen sich damit 3 Fragen:
1.) Wer braucht das?
2.) Wenn das ein privates Projekt ist: ist das nicht vielleicht ein bisschen zu komplex für eine Person allein?
3.) Wenn das ein kommerzielles Projekt ist: wer zum Henker bekommt für derartigen Code Geld???
MfG,
EKKi
Naja, es ist ein privates Projekt und ich code zwischendurch des Spasses halber und nicht ob irgendwelcher kommerziellen Ambitionen. Es ist zwar kein Browsergame, aber im Management - Tool für selbige. Dass der Code kein professionelles Niveau erreicht stört mich nicht. Dafür gibt es ja solche Foren hier wo man sich mal erkundigen kann *g*
Kannst du mir denn evtl. wenigsten einen Ansatz geben, die Javascript-Funktion zu optimieren? Ich lese leider viel Kritik und wenige Vorschläge. Finde ich schade, da du anscheinend ja Ahnung von der Materie hast, nur dass da was nicht stimmt wußte ich vorher ja auch ...
Mmn ist das ganze ein internes JS-Problem, da es keine Möglichkeit gibt, direkte "values" bei Select-Feldern auszuwählen. Man muss immer über den Index gehen. Man könnte zwar in der Datenbank, aus der die Voreinstellungen kommen, statt des values den Index speichern, nur dann dürfte man die Optionen auch nicht mehr verändern in der Reihenfolge, weil ansonsten die Indizes in der Datenbank alle nicht mehr stimmen. Und das geht nicht. Da das Projekt z.Z. auch ein englisches Interface besitzt und ich gewisse Select-Felder alphabetisch durchsortiere ergeben sich halt bei der deutschen und englischen Sprache sofort andere Reihenfolgen, d.h. ich muss über den value gehen, um die gleiche Option in verschiedenen Sprachen selektieren zu können. Oder sehe ich da was falsch?
Und dann bleibt mir doch nichts, außer über eine Schleife (von mir aus auch mit getElementById, wobei das mMn egal ist, da er bei beiden Möglichkeiten nur ein Element findet) solange rumzususchen, bis er den passenden value gefunden hat.
Das ganze ist sicherlich aufwendig (zumal einige select-felder bis zu 30 optionen haben), nur mir fällt zu der Problematik nichts besseres ein :(
Das Problem tritt übrigens im FireFox 2.0.0.x auf, nicht aber im Opera. Da surrt das Script wie ein Kätzchen und ist fühlbar und sichtbar schneller. IE kann ich nicht testen, da das Projekt z.Z. noch nicht kompatibel zum IE ist.
Mahlzeit j0Shi,
Kannst du mir denn evtl. wenigsten einen Ansatz geben, die Javascript-Funktion zu optimieren? Ich lese leider viel Kritik und wenige Vorschläge.
Tut mir leid - allerdings waren Deine bisherigen "Fehlerbeschreibungen" auch eher dürftig.
Finde ich schade, da du anscheinend ja Ahnung von der Materie hast, nur dass da was nicht stimmt wußte ich vorher ja auch ...
... allerdings hast Du es erst nach und nach (durch gezieltes Nachfragen) geschafft, das Problem einigermaßen verständlich zu beschreiben bzw. einzugrenzen.
Mmn ist das ganze ein internes JS-Problem, da es keine Möglichkeit gibt, direkte "values" bei Select-Feldern auszuwählen.
Wie kommst Du darauf? Auch select-Objekte haben eine Eigenschaft namens "http://de.selfhtml.org/javascript/objekte/htmlelemente.htm#select@title=value" ...
Man muss immer über den Index gehen.
Das stimmt so nicht. Aber selbst wenn man lediglich mit selectedIndex arbeiten könnte, wäre der direkte Zugriff damit immer noch schneller als in einer Schleife durch alle Optionen zu gehen.
Und dann bleibt mir doch nichts, außer über eine Schleife (von mir aus auch mit getElementById, wobei das mMn egal ist, da er bei beiden Möglichkeiten nur ein Element findet) solange rumzususchen, bis er den passenden value gefunden hat.
Falsch.
Als Beispiel mal folgendes Stückchen Code:
for (i = 0; i < document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].options.length; i++) {
if (document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].options[i].value == val_arr[2]) document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].options[i].selected = true;
}
Besser wäre:
`document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0].value == val_arr[2];`{:.language-javascript}
Außerdem ist es - wie gesagt - nicht sinnvoll, bei mehreren Zugriffen auf die gleiche <select>-Box das Objekt jedesmal wieder neu im DOM-Baum zu suchen. Für solche Fälle solltest Du es in einer lokalen Variablen speichern:
`var sel = document.getElementsByName('drop_intern_xwars_settings_galasearch_uni')[0];`{:.language-javascript}
> Das ganze ist sicherlich aufwendig (zumal einige select-felder bis zu 30 optionen haben), nur mir fällt zu der Problematik nichts besseres ein :(
Dann hast Du Dich nicht ausreichend informiert.
MfG,
EKKi
--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
Yerf!
Das Problem tritt übrigens im FireFox 2.0.0.x auf, nicht aber im Opera. Da surrt das Script wie ein Kätzchen und ist fühlbar und sichtbar schneller. IE kann ich nicht testen, da das Projekt z.Z. noch nicht kompatibel zum IE ist.
Oh, in dem Fall *willst* du das auch gar nicht im IE (zumindest 6er) probieren...
Die getElement*-Methoden sind bei größerem HTML-Code gerne eine Performance-Bremse. Wobei der IE 6 dabei deutlich langsamer ist als der FF. Opera hat an der stelle seinen Turbo eingeschaltet, dafür hat er an anderen Stellen Defizite[1]...
Man sollte auf jeden Fall versuchen solche Zugriffe zu vermeiden. EKKi hat dir ja schon ein paar Ansätze geliefert.
Gruß,
Harlequin
[1] wir habens mal geschafft durch Optimierungen (bei getElement*-Zugriffen) für den IE es so hinzubekommen, dass Opera und IE ihre Ausführungszeit getauscht hatten... muss wohl an den ganzen Stringoperationen gelegen haben die wir beutzten um die Anzahl der Hidden-Inputs im Formular zu reduzieren (Inhalt mehrer Felder in eines zusammenfassen).
Hi,
Das Problem tritt übrigens im FireFox 2.0.0.x auf, nicht aber im Opera. Da surrt das Script wie ein Kätzchen und ist fühlbar und sichtbar schneller.
Und wenn du im FF mal alle Extensions (so vorhanden) deaktivierst ...?
MfG ChrisB
Hi,
Zwischen den Zeilen lese ich allerdings, dass das ganze wohl ein Performance-Problem meines Rechners darstellt und auf einem modernen Webserver so nicht auftreten sollte.
da eine Webseite auf dem Client gerendert wird, dürfte der Server an der ganzen Geschichte wenig Anteil haben. Ich vermute trotz allem, dass die Vorgänge auf der Seite oder dem Drumherum in irgendeiner Form aufwändiger sind, als es Deine Beschreibung erwarten lässt. Nach wie vor halte ich einen Link zur Problemseite für zielführend.
Das würde mir auch reichen. Trotzdem wäre ich rein interessehalber weiterhin an einer Lösung interessiert, da mehr Speed zwar das Problem beseitigt, nicht aber die Ursache der sequientellen Abarbeitung.
Die sequentielle Abarbeitung liegt daran, dass die JavaScript-Engine Anweisungen, uhm, sequentiell abarbeitet - so wie übrigens praktisch der gesamte Rest Deines Computers auch. Die Geschwindigkeit, in der dies zu passieren scheint, sollte jedoch signifikant höher sein.
Cheatah