New Topic

GeoGebra Topic Problem German

Category German

Tags zeigeAchsen

Due On 2020-02-08

sorry, it's not solved

Comments

Participants

Subscribers

Votes

Views

647

Bremst "ZeigeAchsen" (showAxes) Applets?

Walter Füchte shared this problem 2 years ago

Solved

In einem Applet werden komplexe parametrisierte Kurven berechnet und angezeigt: das ist zeitaufwendig - Ladezeit, Rechenzeit.

Die Kurven hängen ab von wenigen Daten: Punkte/Geraden und/oder Slider. Damit nicht jede Änderung das Applet verzögert, werden die Daten als "dummies" bewegt. Erst ein Schalter "neu berechnen" setzt die Original-Daten, womit die Berechnung der Kurven neu beginnt.

Das funktioniert gut, solange der Skriptbefehl "ZeigeAchsen"(showAxes) nicht ausgelöst wurde.

Danach aber sind auch die "dummies" blokiert(!) und das Applet ist stark gebremst!

In speedtest ist dasselbe Applet oben mit selbsterzeugten Koordinatenachsen und Punkten, unten mit "zeigeAchsen": zum Test! (längere Ladezeiten wegen der parametrisierten Kurven!)

Andere Beispiele: Kreisbüschel wurzeln (eigenes KOS)

und Kreisbüschel wurzeln 2 (mit "ZeigeAchsen")

In Bewunderung für geogebra grüßt W.F.

The same problem

Comments (5)

rami ● 2 years ago

Ich denke es liegt am Umschalten der Sichtbarkeit der Achsen durch einen Skript-Befehl und nicht an daran ob die Achsen sichtbar sind oder nicht.

Begründbare Vermutung: Sobald "ShowAxes()" das erste mal ausgeführt wird, dann ist onUpdate für einige oder alle Objekte immer erfüllt, was genau soviel Performance benötigt als ob man ohne den Button "neu berechnen" (und ohne dummies) arbeiten würde. (Der alte Zustand, ohne die neuen dummies wird unnötigerweise neu berechnet.)

Dabei haben keinen Einfluss

die parameter Inhalte (true, false)
die Syntaxform (mit oder ohne <view>)
die Sprache
mit/ohne Execute()
Einbettung in Bolean oder etwas anderes (zB slider 0 bis 1,step1)
als GGB- oder JS

Es handelt sich meiner Ansicht nach eindeutig um einen Bug (GGB5 und GGB6).

Das Einzige was funktioniert ist die Verwendung der Style-Bar (Hintergrund, Achsen)

Die einzige Umgehungslösung hast Du bereits gefunden: den Befehl nicht anwenden.

Allenfalls könnte man die zeitkritischen Listen im Skript abhandeln

SetzeWert(<freie liste>, KopiereFreiesObjekt(Zip(.......)))

Dies setzt die Definition von "<freie liste>={}" voraus und dass in der Initialphase der Skript aufgerufen wird. Abhängige Objekte müssten mit einen undefinierten Zustand von <freie liste> umgehen können. Diese Umgehungslösung könnte recht aufwändig werden. Da ist das Erstellen einer eigenen Achse massiv einfacher und auch in der Performance erheblich besser.

------------------

Falls meine Vermutung zutrifft, so handelt es sich (ebenfalls vermutlich) insofern um einen kritischen Fehler, als er ein sehr komplexes Gebiet betrifft, bei dem man, ohne viel GGB-KnowHow und Sorgfalt, eher 2 neue Fehler einbaut als einen behebt.

Reply URL

Walter Füchte ● 2 years ago

Danke, rami, für die genaue, sorgfältige und aufwändige Analyse! Deine Vermutung zu OnUpdate() nach Auslösung des Skriptbefehls entspricht genau meinem vagen "Gefühl", als würden durch den Befehl auf alle Objekte "Lauscher" gesetzt, die bei jeder Änderung Neuberechnung anstoßen.

Ich werde den Skriptbefehl durch eigene KOS-Achsen ersetzen: ist bei mehreren Applets zu komplexen Funktionen nötig - ein bißchen zeitaufwendig.

Die Rechenzeiten bei Listen von parametrisierten Kurven muss ich wohl in Kauf nehmen, manchmal wünschte ich mir ein rotierendes Rädchen (wie beim Laden eines Applets!), um anzuzeigen, dass sich was tut. Eine Idee dazu?

Vielen Dank und Gruss von W.F.

URL

rami ● 2 years ago

hier eine mögliche Lösung

Ich bin nicht ganz (aber fast) sicher, dass diese Lösung sinngemäss in Deiner Umgebung laufen sollte und keinen Schalter "neu berechnen" benötigt (automatisiert per timeout)

Bei Problemen mit diesem Prinzip bitte Feedback mit kurzem Kommentar und mit ggb-File.

Files: dummyParam02.gg...

URL

Walter Füchte ● 2 years ago

Hallo Raymond, danke für Deine Unterstützung und Übersetzung. Leider ohne Wirkung!

Ich hatte in den Applets timeout teilweise wieder entfernt, solange ich die Ursache der Bremswirkung nicht gefunden habe. Ohne "ZeigeAchsen" oder "ZeigeGitter" ist timeout genau richtig: Danke.

Das Rädchen ist hübsch, aber ich vermute, eine absolute Position ist nicht möglich. Es kann also beim Zoomen oder KOS-Verschieben verschwinden.

Ein Objekt vorübergehend auf Undefiniert zu setzen, gelingt mit nicht mit Listen, nur mit Zahlen oder Punkten.

Es scheint mir aber auch nicht mehr nötig zu sein: Ein Text "wait" zeigt, dass sich was tut: als Bedingung reicht "timeout<>1" dazu speed test 2

Gruss W.F.

URL

Walter Füchte ● 2 years ago

Nachtrag: der Skriptbefehl "ZeigeGitter" hat wohl dieselbe Bremswirkung.

W.F.

Reply URL