Pregunta

Estoy creando un animador de la red (similar a nam, si ha usado antes).

Básicamente, tengo nodos representados como pequeños puntos en un GTK + DrawingArea, y actualizar las posiciones de estos nodos y volver a dibujar el DrawingArea en un bucle.

La animación resultante es rápido, pero no sin problemas (hay una gran cantidad de parpadeo). Esto es probablemente porque lleno el DrawingArea con un color sólido antes de cada marco.

¿Cómo cree que puedo abordar mejor este problema? Debería preprocese los marcos Onto pixbuffers? ¿Hay una solución mejor?

Aquí está mi código de dibujo actual (usando 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)

donde self.t es la hora actual, que se incrementa en el bucle.

¿Fue útil?

Solución

He cambiado mi código para hacer que los marcos en un mapa de puntos, y sustituyó a la DrawingArea con una imagen.

Si bien esto resuelve el parpadeo, ahora el uso de la CPU ha alcanzado su pico. La animación es todavía bastante rápido, pero no creo que este método es escalable.

¡Un poco de optimización, supongo.

ACTUALIZACIÓN: Resulta usando exponer al evento con una imagen no fue tan buena idea. uso de la CPU es volver a la normalidad.

Otros consejos

Acerca del manejo del evento exponer, echa un vistazo al primer párrafo de animaciones con El Cairo + Gtk: P

  

Animación Multi-roscado con El Cairo y GTK +
  animaciones complejas con   El Cairo y GTK + puede resultar en una interfaz laggy. Esto se debe a la   gtk_main () hilo se ejecuta en un solo bucle. Por lo tanto, si su do_draw ()   función implementa un comando complicado dibujo, y se llama   Del hilo gtk_main () (digamos por un on_window_expose_event ()   función), el resto de su código GTK se bloqueará hasta que la   do_draw () la función termina. Consecuentemente, los elementos de menú, ratón   clics, y ni siquiera cerca de eventos de botón será lento para ser procesado y   su interfaz se sentirá lag.

     

Una solución es a mano fuera todo el dibujo intensivo del procesador a una   hilo separado, liberando así el hilo gtk_main () para responder a   eventos.

http://cairographics.org/threaded_animation_with_cairo/

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top