C'est juste plus lent qu'en "small", ça ne s'aggrave pas avec le temps. Je suppose que ça doit faire pareil chez toi, non ?
Si je comprends bien ton code,
glib.timeout_add(10, self.on_timer)
toutes les 10 ms, tu appelles la fonction on_timer() qui appelle inc_old_score_to_score() pour modifier le score affiché (de sorte qu'avec la fréquence importante, on a l'impression que ça monte continument) et au bout de 30 fois on arrête (car timer_counter est initialisé à 30 et décrémenté à chaque fois).
Je ne comprends pas tout l'algo, mais je ne vois pas où la taille intervient. En ajoutant un print self.timer_counter, je vois bien les 30 itérations, et je vois bien que c'est plus lent en "extra large", mais je ne vois pas pourquoi, sinon pour des raisons de temps-réel, mais alors je ne vois pas ce qui se passe qui retarde.
[^] # Re: Bien !
Posté par jihele . En réponse à la dépêche Bubble Crusher 0.9 bêta release. Évalué à 1.
Pas de quoi.
C'est juste plus lent qu'en "small", ça ne s'aggrave pas avec le temps. Je suppose que ça doit faire pareil chez toi, non ?
Si je comprends bien ton code,
toutes les 10 ms, tu appelles la fonction on_timer() qui appelle inc_old_score_to_score() pour modifier le score affiché (de sorte qu'avec la fréquence importante, on a l'impression que ça monte continument) et au bout de 30 fois on arrête (car timer_counter est initialisé à 30 et décrémenté à chaque fois).
Je ne comprends pas tout l'algo, mais je ne vois pas où la taille intervient. En ajoutant un print self.timer_counter, je vois bien les 30 itérations, et je vois bien que c'est plus lent en "extra large", mais je ne vois pas pourquoi, sinon pour des raisons de temps-réel, mais alors je ne vois pas ce qui se passe qui retarde.