Quelque soit le type de fenetre, ca marche toujours avec une boucle principal (main loop) et des callbacks asynchrones sur evenements. Ce qui genere des freezes, c'est quand le temps passe dans les callbacks de ton application ne laisse plus le temps au code de rendu graphique pour faire le dit rendu en moins de 1/60 seconde. Il y a plein de chose qui peuvent generer des freezes en plus de calcul un peu long, acces au disque non asynchrone, acces reseau non asynchrone, rendu inutile, ... En mettant le rendu dans un thread separe (meme si il faut le piloter), tu te retrouves a avoir un peu plus de temps entre le dernier moment ou tu l'as piloter et le moment ou tu dois le piloter. Combiner avec des IO asynchrones un peu partout, tu eviteras les freezes et tiendra les 60 fps, si ton second core et le code de rendu en est capable.
[^] # Re: Intérêt
Posté par cedric . En réponse à la dépêche Haiku est vivant. Évalué à 2.
/o\ Euh, juste non. Il n'y a aucun rapport.
Quelque soit le type de fenetre, ca marche toujours avec une boucle principal (main loop) et des callbacks asynchrones sur evenements. Ce qui genere des freezes, c'est quand le temps passe dans les callbacks de ton application ne laisse plus le temps au code de rendu graphique pour faire le dit rendu en moins de 1/60 seconde. Il y a plein de chose qui peuvent generer des freezes en plus de calcul un peu long, acces au disque non asynchrone, acces reseau non asynchrone, rendu inutile, ... En mettant le rendu dans un thread separe (meme si il faut le piloter), tu te retrouves a avoir un peu plus de temps entre le dernier moment ou tu l'as piloter et le moment ou tu dois le piloter. Combiner avec des IO asynchrones un peu partout, tu eviteras les freezes et tiendra les 60 fps, si ton second core et le code de rendu en est capable.