Rolf B: Mehrere requestAnimationFrame() ...problematisch?

Beitrag lesen

Hallo 1unitedpower,

Ist es eigentlich prinzipiell zulässig [bzw. wohl eher ratsam] sowie Good Practice, mehrere requestAnimationFrame() parallel ablaufen zu lassen?

Klar ist das zulässig. Kleiner Tipp am Rande: Du meinst "konkurrierend" bzw. "asynchron" und nicht "parallel".

Zulässig vielleicht, aber in JavaScript nicht möglich. Die requestAnimationFrame Callbacks werden strikt nacheinander ausgeführt. JavaScript ist an dieser Stelle nicht parallelisierbar. Ob der Grafiktreiber oder die Grafikhardware es in anderen Sprachen zulässt, dass zwei Threads am gleichen Grafikkontext herumspielen - oder an zwei Grafikkontexten für verschiedene Bildschirmbereiche - oder ob auch da sequenziert werden muss, keine Ahnung.

Man kann natürlich Berechnungen in Worker Threads auslagern. Mit denen kommuniziert man in JavaScript aber asynchron über postMessage und fängt sich damit den Overhead des Messagings ein. Ich habe auch keine Ahnung, ob es dabei zu unkalkulierbaren Verzögerungen kommen kann, die innerhalb einer requestAnimationFrame Verarbeitung nicht tolerierbar sind. Das eigentliche Zeichnen muss man aber auf jeden Fall im UI-Thread machen, das geht nicht im Worker.

In einem Spiel könnte ich mir vorstellen, dass die Physik der Spielwelt in einem Worker läuft. Immer, wenn die Physik eines Frames neu berechnet ist, wird mit postMessage ein Datenpaket bereitgestellt, das der UI Thread dann zum Zeichnen verwendet. Wenn der User Kommandos gibt, werden diese mit postMessage dem Worker übermittelt und der bezieht sie in die Berechnung des nächsten Frames ein. Ob das funktioniert - keine Ahnung. Ob es effizient ist und nicht laggt[1] - ebensowenig Ahnung. Um das zu merken, braucht man schon ein komplexes Spiel, das in einer single-thread Lösung einknickt.

Rolf

--
sumpsi - posui - obstruxi

  1. Zur Illustration des Problems: Daniel LaBelle - If people lagged in real life ↩︎