Question

Je crée un animateur de réseau (similaire à nam, si vous avez utilisé avant).

Fondamentalement, je noeuds représentés sous la forme de petits points sur un GTK + DrawingArea, et mettre à jour les positions de ces noeuds et redessiner la DrawingArea dans une boucle.

L'animation résultante est rapide, mais pas lisse (il y a beaucoup de scintillement). Ceci est probablement parce que je remplirai le DrawingArea avec une couleur unie avant chaque image.

Comment pensez-vous que je peux mieux aborder ce problème? Dois-je effectuer une pré-rendu des images pixbufs ONTO? Y at-il une meilleure solution?

Voici mon code de dessin en cours (en utilisant PyGTK):

rect  = self.drawing_area.get_allocation()
style = self.drawing_area.get_style()

pos   = [n.position_at(self.t) for n in self.nodes]

self.drawing_area.window.draw_rectangle(style.bg_gc[gtk.STATE_NORMAL], True,
                                        0, 0, rect.width, rect.height)

for p in pos:
    self.drawing_area.window.draw_arc(style.fg_gc[gtk.STATE_NORMAL], True,
                                      rect.width  * (p.x / 2400.0) - NODE_SIZE/2,
                                      rect.height * (p.y / 2400.0) - NODE_SIZE/2,
                                      NODE_SIZE, NODE_SIZE,
                                      0, 64 * 360)

self.t est l'heure courante, qui est incrémenté dans la boucle.

Était-ce utile?

La solution

J'ai changé mon code pour rendre les images sur un Pixmap, et a remplacé le DrawingArea avec une image.

Bien que cela a résolu le vacillement, maintenant l'utilisation du processeur a atteint un sommet. L'animation est encore assez rapide, mais je ne pense pas que cette méthode est évolutive.

Temps pour une optimisation, je suppose.

Mise à jour: Il se trouve à l'aide d'exposer événement avec une image n'a pas été une bonne idée. l'utilisation du processeur est de retour à la normale.

Autres conseils

A propos de la tenue de route événement exposer, consultez le premier paragraphe Animations avec le Caire + Gtk: P

  

Animation multi-thread avec le Caire et GTK +   animations complexes   caire et GTK + peut entraîner une interface laggy. En effet, le   gtk_main fil () fonctionne dans une seule boucle. Donc, si votre do_draw ()   Fonction Met en oeuvre une commande de dessin compliqué, et il est appelé   du filetage gtk_main () (-dire par un on_window_expose_event ()   fonction), le reste de votre code gtk sera bloqué jusqu'à ce que le   do_draw fonction () se termine. Par voie de conséquence, les éléments de menu, souris   clics, et même des événements de bouton de fermeture seront lents à traiter et   votre interface se sentira laggy.

     

Une solution consiste à la main hors tout le dessin de processeur à forte intensité à une   thread séparé, libérant ainsi le fil gtk_main () pour répondre à   événements.

http://cairographics.org/threaded_animation_with_cairo/

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top