Pergunta

Estou criando um animador de rede (semelhante ao nam, se você tê-lo usado antes).

Basicamente, eu tenho nós representados como pequenos pontos em um GTK + DrawingArea, e eu atualizar as posições destes nós e redesenhar o DrawingArea em um loop.

A animação resultante é rápido, mas não suavizar (há um monte de flicker). Este é provavelmente porque eu preencher o DrawingArea com uma cor sólida antes de cada quadro.

Como você acha que eu posso melhor lidar com este problema? Devo pré-processar os quadros Onto Pixbufs? Existe uma solução melhor?

Aqui está o meu código de desenho atual (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)

onde self.t é o momento atual, que é incrementado no circuito.

Foi útil?

Solução

Eu mudei meu código para processar os quadros em um Pixmap, e substituiu o DrawingArea com uma imagem.

Enquanto isso resolveu o cintilação, agora o uso da CPU atingiu o pico. A animação ainda é bastante rápido, mas eu não acho que este método é escalável.

Hora para alguma otimização, eu acho.

UPDATE: Acontece usando expor-evento com uma imagem não era tal uma boa idéia. uso da CPU está de volta ao normal.

Outras dicas

Sobre a manipulação expor-evento, confira o primeiro parágrafo da Animações com Cairo + Gtk: P

Multi-threaded Animação com Cairo e GTK +
animações complexas com cairo e GTK + pode resultar em uma interface lag. Isso ocorre porque o gtk_main () é executado de rosca em um único circuito. Assim, se seu do_draw () implementa a função de um comando de desenho complicado, e é chamado da rosca gtk_main () (dizem por um on_window_expose_event () função), o resto do seu código GTK será bloqueado até que o do_draw () acabamentos de função. Conseqüentemente, os itens do menu, rato cliques e eventos de botão até próximo será lenta para ser processado e sua interface vai se sentir lag.

Uma solução é mão fora todo o desenho do processador a um thread separada, libertando assim o fio gtk_main () para responder a eventos.

http://cairographics.org/threaded_animation_with_cairo/

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top