digitaler zwilling in python/tkinter

[reinerdoll]

ich habe (laienhaft !) eine grafik geschrieben, die eine kleine anlage darstellt.
(es werden kleine bauteile auf ein transportband gelegt und dort von station zu station verschoben)

alles ist in einem einzigen "tkinter.canvas" modelliert.
die bauteile bewege ich mit der .move - methode.
es klappt auch alles sehr gut, bauteile bleiben z.b. stehen wenn sie wo auflaufen, usw., usw.

ein einziges problem krieg ich nicht gelöst : die grafik wird beim teileschieben immer langsamer !
es liegt nicht an der cpu, mit .after(30) kann ich die cpu-last gut unter 100% halten.
die steuerung der animation geschieht über einen tcp-socket, der bremst aber auch nicht.

die stuktur ist so :

import tkinter as tk
twin = tk.Canvas(width=2000, height=800)

-massig zeichnung-

while True :

-animation-

twin.update()
twin.after(30)


wieso wird das immer langsamer ??

[reinerdoll]

eine idee ...

ich ändere objektfarben, indem ich einfach neue (andersfarbige) objekte über die alten drüberschreibe.
könnte es sein, daß die steigende anzahl von objekten die sache langsamer macht ?

[Sirius3]

Mit dem Code-Fragment kann man die Frage nicht beantworten. Aber natürlich wird alles langsamer, wenn Du ständig noch mehr Objekte zeichen läßt.
`update` hat in einem sauberen GUI-Programm nichts verloren. Das `after` hat keinen Effekt.
Warum hast Du nichts von dem übernommen, was wir vor ein paar Monaten so mühsam erarbeitet haben?

[reinerdoll]

einfacher grund : was da läuft ist die obergrenze von code, den ich noch verstehe. ich bin kein software-profi ;-(

weil ich die grafik aus einem socket von einem anderen rechner aus steuern muß, brauch ich eine schleife.
versuche, die grafik mit threading zu isolieren (versuch "in richtung saubere gui") sind wegen zeile 1 gescheitert.

ich habs nochmal getestet : der effekt der verlangsamung tritt auch auf, wenn ich die aktualisierung der farben durch überschreiben nicht mache.

ich weiß schon (hab ich nicht vergessen, was ihr mir erklärt habt) die struktur taugt nichts. aber es läuft eben "fast", da ist die motivation, es komplett neu zu schreiben, schwierig...

[Sirius3]

Da du immer noch keinen Code zeigst, der das Problem illustriert, kann man immer noch nichts dazu sagen.
Zusammengemurkster Code wird immer an einer Stelle nicht mehr funktionieren, und die Fehlersuche umständlich bis unmöglich. Das wird auch bei gutem Code passieren, aber deutlich seltener, und dann ist der Aufwand das zu beheben deutlich geringer.

[reinerdoll]

ich habs gefunden.
es war doch so, wie ich vermutet habe. ich habe aus versehen in der hauptschleife teile erzeugt, das sind dann natürlich massig viele geworden.

ich denke mein stümper-code ist nicht so spannend, oder ?

läuft aber : eine recht brauchbare simulation einer kleinen anlage, die über socket aus einem steuerechner bedienbar ist.

[Sirius3]

Spannend, weil es wahrscheinlich großer Zufall ist, dass das überhaupt funktioniert.

[reinerdoll]

kann ich hier keine anhänge (.zip) an den beitrag hängen ?
der code ist ja wahnsinnig lang ...