[Monkey] Update befehle in OnReander ausführen

Übersicht

Andere Programmiersprachen

Beginners-Corner

	Dottakopf Betreff: Update befehle in OnReander ausführen	Fr, März 20, 2015 18:47 Antworten mit Zitat
Hallo Blitzer und Monkeys, in Monkey gibt es ja die Klassen OnUpdate() OnRender() etc. Nun habe ich festgestellt das ich einige klassen habe in denen ich aus Performancegründen nicht nur Male sondern auch die Objekte bewege/berechne. Hintergrund, ich will nicht die liste durchgehen, alles Updaten, und dann im OnRender nochmal alles durchgehen und alles zeichnen. Immerhin spare ich mir einen ganzen durchlauf aller Objekte. Bekomme ich da irgendwann Probleme ? Oder ist das jetzt einfach nur etwas umsauber ? Evt. Macht macht Monkey in der OnRender ja irgendwas internes tolles, iwas was Zeichenbefehle super schnell macht aber normale Berechnung tatsächlich langsamer ? Sowas wie.. Berechnung auf der Graka statt im RAM, hm hm.. Danke !! Gruß Dottakopf
Rechtschreibfehler gelten der allgemeinen Belustigung!

Dottakopf

Betreff: Update befehle in OnReander ausführen

Fr, März 20, 2015 18:47
Antworten mit Zitat

Hallo Blitzer und Monkeys,

in Monkey gibt es ja die Klassen OnUpdate() OnRender() etc.
Nun habe ich festgestellt das ich einige klassen habe in denen ich aus Performancegründen nicht nur Male sondern auch die Objekte bewege/berechne. Hintergrund, ich will nicht die liste durchgehen, alles Updaten, und dann im OnRender nochmal alles durchgehen und alles zeichnen.

Immerhin spare ich mir einen ganzen durchlauf aller Objekte.
Bekomme ich da irgendwann Probleme ? Oder ist das jetzt einfach nur etwas umsauber ?

Evt. Macht macht Monkey in der OnRender ja irgendwas internes tolles, iwas was Zeichenbefehle super schnell macht aber normale Berechnung tatsächlich langsamer ? Confused

Sowas wie.. Berechnung auf der Graka statt im RAM, hm hm..

Danke !!

Gruß
Dottakopf

Rechtschreibfehler gelten der allgemeinen Belustigung!

	Silver_Knee	Fr, März 20, 2015 20:06 Antworten mit Zitat
Ich glaube du kannst dir nur sicher sein, dass Grafik-Befehle korrekt in OnRender ausgeführt werden. Vielleicht passiert bei deinem Target etwas wie: Code: [AUSKLAPPEN] [EINKLAPPEN] ActivateDrawing() app.OnRender() Flip Cls DeactivateDrawig() und das Aufrufen von Zeichhenbefehlen außerhalb dieser Klammer ist verboten, so ähnlich wie mit LockBuffer, ReadPixelFast, WritePixelFast und UnlockBuffer in BlitzBasic. Berechnungen dort auszuführen ist vielleicht nicht so Schlau, weil laut Definition nur zirka die UpdateRate eingehalten wird. Das Target kann dann auch mal n Frame überspringen. Mach die Schleifen ruhig 2 mal. Dann stören die Berechnungen auch nicht während der Anzeigeroutine und bremsen diese aus. Im besten Fall kannst du bei der Berechnung eine Liste, Map oder andere Collection zusammenstellen bei der du nur alle zu zeichnenden Elemente einreihst und diese Zahl ist viel kleiner als die Gesamtzahl. Dann muss OnRender nicht mehr alle durchgehen. Kommt aber drauf an wie viel kleiner die Zahl ist, ob das schneller ist, als alle durchzugehen. Außerdem kannst du so die Zeichenreihenfolge von der Verarbeitungsreihenfolge trennen: Fenster zum Beispiel werden von hinten nach vorne gezeichnet, verarbeiten aber Klicks von vorne nach hinten.

Silver_Knee

Fr, März 20, 2015 20:06
Antworten mit Zitat

Ich glaube du kannst dir nur sicher sein, dass Grafik-Befehle korrekt in OnRender ausgeführt werden.

Vielleicht passiert bei deinem Target etwas wie:

Code: [AUSKLAPPEN]

ActivateDrawing()
app.OnRender()
Flip
Cls
DeactivateDrawig()

und das Aufrufen von Zeichhenbefehlen außerhalb dieser Klammer ist verboten, so ähnlich wie mit LockBuffer, ReadPixelFast, WritePixelFast und UnlockBuffer in BlitzBasic.
Berechnungen dort auszuführen ist vielleicht nicht so Schlau, weil laut Definition nur zirka die UpdateRate eingehalten wird. Das Target kann dann auch mal n Frame überspringen.

Mach die Schleifen ruhig 2 mal. Dann stören die Berechnungen auch nicht während der Anzeigeroutine und bremsen diese aus.
Im besten Fall kannst du bei der Berechnung eine Liste, Map oder andere Collection zusammenstellen bei der du nur alle zu zeichnenden Elemente einreihst und diese Zahl ist viel kleiner als die Gesamtzahl. Dann muss OnRender nicht mehr alle durchgehen. Kommt aber drauf an wie viel kleiner die Zahl ist, ob das schneller ist, als alle durchzugehen.
Außerdem kannst du so die Zeichenreihenfolge von der Verarbeitungsreihenfolge trennen: Fenster zum Beispiel werden von hinten nach vorne gezeichnet, verarbeiten aber Klicks von vorne nach hinten.

	DAK	Fr, März 20, 2015 23:12 Antworten mit Zitat
Kurzform: Sehr unsauber, sehr böse, nicht machen! Langform: Performance-Technisch bringt dir das fast keinen Gewinn. Eine Liste durchgehen kostet dich kaum Rechenleistung. Was kostet ist die Verarbeitung. Ob du die Liste zwei Mal durchgehst und dabei je eine Verarbeitung (Update und Render) hast, oder ob du die Liste ein Mal durchgehst und in dem einen Mal beide Verarbeitungen drin hast macht kaum einen Unterschied. Probier's mal aus. Je nach den Verarbeitungen wird dein Geschwindigkeitsgewinn im Bereich von <1% (bei komplexeren Verarbeitungen) bis zu vielleicht 5% (bei trivialen Verarbeitungen, wo du eh mehr als genug Rechenzeit übrig hast) liegen. Eventuell verringerst du sogar die Verarbeitungsgeschwindigkeit, da ja nach dem wie das Framework funktioniert (habe Monkey noch nie verwendet, weiß das also nicht) eventuell onUpdate und onRender in zwei verschiedenen Threads laufen. In diesem Fall würdest du auf einem Multicore-System Performance verlieren! Das Dritte ist, dass du so eventuell zu seltsamen Abstürzen kommst. Auf Android z.B. wird die Verarbeitung in einen Render-Thread und einen (oder mehrere) Worker-Threads unterteilt. Die Worker arbeiten onUpdate ab, der Render-Thread macht onRender. Android hat hier eine Erkennung, ob ein Programm abgestürzt ist: wenn der Render-Thread länger als 200ms für ein Frame braucht, dann denkt Android, dass das Programm abgestürzt ist, und bringt es um. Außerdem blockiert Android die Verwendung von typischen nicht-render-Befehlen wie z.B. Netzwerkbefehlen auf dem Render-Thread. In diesem Sinne: Finger weg von nutzlosen Mikrooptimierungen und folge den Standards. Die Leute, die diese Standards aufgestellt haben, die haben sich schon was dabei gedacht Generell: Wir sind nicht mehr in C64er-Zeiten. Mikrooptimierungen werden schon von dem Compiler gemacht, und der weiß generell besser, wie er den Code optimieren muss, als wir. Die Dinger sind schon ganz sinnvoll geschrieben. Mit Mikrooptimierungen sorgt man nur dafür, dass der Compiler nicht mehr sinnvoll optimieren kann. Hab schon oft genug gesehen, dass Mikrooptimierungen die Programme sogar langsamer gemacht haben, und nicht schneller.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Fr, März 20, 2015 23:12
Antworten mit Zitat

Kurzform: Sehr unsauber, sehr böse, nicht machen!

Langform:
Performance-Technisch bringt dir das fast keinen Gewinn. Eine Liste durchgehen kostet dich kaum Rechenleistung. Was kostet ist die Verarbeitung. Ob du die Liste zwei Mal durchgehst und dabei je eine Verarbeitung (Update und Render) hast, oder ob du die Liste ein Mal durchgehst und in dem einen Mal beide Verarbeitungen drin hast macht kaum einen Unterschied. Probier's mal aus. Je nach den Verarbeitungen wird dein Geschwindigkeitsgewinn im Bereich von <1% (bei komplexeren Verarbeitungen) bis zu vielleicht 5% (bei trivialen Verarbeitungen, wo du eh mehr als genug Rechenzeit übrig hast) liegen.

Eventuell verringerst du sogar die Verarbeitungsgeschwindigkeit, da ja nach dem wie das Framework funktioniert (habe Monkey noch nie verwendet, weiß das also nicht) eventuell onUpdate und onRender in zwei verschiedenen Threads laufen. In diesem Fall würdest du auf einem Multicore-System Performance verlieren!

Das Dritte ist, dass du so eventuell zu seltsamen Abstürzen kommst. Auf Android z.B. wird die Verarbeitung in einen Render-Thread und einen (oder mehrere) Worker-Threads unterteilt. Die Worker arbeiten onUpdate ab, der Render-Thread macht onRender.
Android hat hier eine Erkennung, ob ein Programm abgestürzt ist: wenn der Render-Thread länger als 200ms für ein Frame braucht, dann denkt Android, dass das Programm abgestürzt ist, und bringt es um.
Außerdem blockiert Android die Verwendung von typischen nicht-render-Befehlen wie z.B. Netzwerkbefehlen auf dem Render-Thread.

In diesem Sinne: Finger weg von nutzlosen Mikrooptimierungen und folge den Standards. Die Leute, die diese Standards aufgestellt haben, die haben sich schon was dabei gedacht Wink

Generell: Wir sind nicht mehr in C64er-Zeiten. Mikrooptimierungen werden schon von dem Compiler gemacht, und der weiß generell besser, wie er den Code optimieren muss, als wir. Die Dinger sind schon ganz sinnvoll geschrieben. Mit Mikrooptimierungen sorgt man nur dafür, dass der Compiler nicht mehr sinnvoll optimieren kann. Hab schon oft genug gesehen, dass Mikrooptimierungen die Programme sogar langsamer gemacht haben, und nicht schneller.

Gewinner der 6. und der 68. BlitzCodeCompo

	Dottakopf	Sa, März 21, 2015 9:17 Antworten mit Zitat
Hallo, danke für die Hilfe! Hatte gestern tatsächlich noch die Methoden umgeändert und richtig ausgelagert. Um so länger ich auf den Codeaufbau geschaut hatte um so störender fand ich es irgendwie. Danke für die technischen Aspekte, ist garnicht verkehrt diese ungefähr zu kennen. @Silver: in der OnUpdate lässt sich Drawimage z.B. garnicht erst compelieren Gruß Dottakopf
Rechtschreibfehler gelten der allgemeinen Belustigung!

Dottakopf

Sa, März 21, 2015 9:17
Antworten mit Zitat

Hallo,

danke für die Hilfe!
Hatte gestern tatsächlich noch die Methoden umgeändert und richtig ausgelagert. Um so länger ich auf den Codeaufbau geschaut hatte um so störender fand ich es irgendwie.

Danke für die technischen Aspekte, ist garnicht verkehrt diese ungefähr zu kennen.

@Silver: in der OnUpdate lässt sich Drawimage z.B. garnicht erst compelieren Smile

Gruß
Dottakopf

Rechtschreibfehler gelten der allgemeinen Belustigung!

Übersicht

Andere Programmiersprachen

Beginners-Corner

Nach Oben

BlitzBasic Portal

[Monkey] Update befehle in OnReander ausführen

Dottakopf

Betreff: Update befehle in OnReander ausführen

Silver_Knee

DAK

Dottakopf