Est-ce que Sprite Kit est rendu en arrière-plan ou sur le thread principal? Comment ça marche?

La documentation montre un runloop simplifié de Sprite Kit.

J'essaie de comprendre comment ils l'ont mis en œuvre. Un SKView appelle -update: sur un SKScene . Cela évalue ensuite les actions, puis simule la physique et permet à la sous-class d'ajuster la scène. Une fois les modifications apscopes à la scène, SKView restitue l'arborescence de nœuds à l'écran.

Ce que je ne comprends pas sont les détails fins. Est-ce que Sprite Kit dissocie les calculs de scène du rendu de scène en utilisant différents threads ou files d'attente GCD? Est-ce qu'il effectue tous les appels de rendu OpenGL en arrière-plan, ou tout se passe-t-il sur le thread principal? À quels points le Sprite Kit passe-t-il d'un fond à l'autre et comment synchronise-t-il le traitement de la scène avec le rendu de la scène? Que se passe-t-il lorsque vos mises à jour de scène prennent trop de time?

Le graphique à secteurs dans la documentation liée montre la boucle de rendu pour Sprite Kit. Chaque partie de la boucle est exécutée de manière synchrone sur le thread principal. Le rendu OpenGL est effectué par SKView à la fin de la boucle de rendu.

Tout comme n'importe quelle boucle de rendu, si la partie de mise à jour prend trop de time, l'intervalle de time de trame est dépassé. Cela entraînera le rendu de la trame sur la prochaine synchronisation, c'est-à-dire une réduction de la fréquence d'images.

Le rendu lui-même est effectué comme avec GLKit: la boucle de rendu est synchronisée sur la fréquence d'actualisation de l'affichage à l'aide d'un CADisplayLink , la propriété frameInterval contrôlant le nombre d'actualisations d'affichage par boucle de rendu. Une fois la mise à jour du model terminée, l'état GL est alors envoyé au GPU et [EAGLContext presentRenderbuffer:] est appelé pour afficher le rendu de rendu SKView. La boucle est maintenant terminée et ne redémarrera pas avant que la binding d'affichage ne se triggers, indiquant que la trame précédente a été rendue et qu'une autre peut être envoyée à l'écran.

Que le rendu se produise ou non sur le thread principal n'est pas documenté et impossible à savoir, mais il s'agit uniquement d'un détail d'implémentation. Si cela se produisait sur un thread différent, alors l'arborescence entière du model devrait être dupliquée dans le thread de rendu, ou un état suffisant pour qu'une image puisse être rendue, alors que le model est mis à jour pour l'image suivante. Très probablement, il est juste synchrone sur le fil principal. Le locking serait inutile, si vous voulez empêcher le thread principal d'accéder à l'état jusqu'à ce que vous ayez fini le rendu, vous pouvez tout aussi bien faire le rendu sur le thread principal.