./39 > Mais a tu testé ton code sur une configuration "limite" au lieu d'un super PC ?
Pour des raisons de consistance, tu dois toujours gérer tous les évènements strictement avant le dessin de l'image (il ne doit pas y avoir de delay entre ces deux opérations). Cela a pour effet que toute action effectuée par l'utilisateur pendant que l'image « x » est à l'écran se reflètera immédiatement sur l'image « x + 1 » (je considère le temps de dessin et d'affichage comme nul pour simplifier). Si tu cases un sleep entre les deux, tu auras des évènements avec un retard d'une image (pas systématiquement, mais la probabilité est élevée).
Donc tu ne peux mettre ton sleep qu'entre le rendu et la gestion des évènements, mais pas dans le sens inverse. Seulement dans ce cas c'est du prédicitf (en fait je n'avais même pas considéré l'autre option… d'où mon post précédent) donc non fiable, et tu peux potentiellement perdre des frames. (voir ce que j'ai écrit avant)
Bien sûr tout ça requiert de tester ton algo sur une configuration inférieure, ce que tu peux simuler justement en casant des sleep avec temps d'attente fixe dans ta boucle de rendu.
C'est clair qu'à 60 FPS, une image c'est un temps « insignifiant », mais quand ton jeu tombe à 11 FPS (c'est pas hors du commun), un retard d'une image, ou des fps perdues en l'air ça devient facilement remarquable par l'utilisateur. (Et c'est horripilant)

(Même chose pour Brunni)