Problema de disparo do QTimer no QGIS (Quantum GIS)

Question

Estive envolvido na construção de um aplicativo QGIS personalizado no qual os dados ao vivo devem ser mostrados no visualizador do aplicativo.

O IPC usado são filas de mensagens unix.

Os dados devem ser atualizados em um intervalo especificado, digamos, 3 segundos.

Agora, o problema que estou enfrentando é que o processamento dos dados a serem mostrados está demorando mais de 3 segundos, então o que fiz foi que antes que o aplicativo começasse a processar os dados para a próxima atualização, a atualização do QTimer foi interrompida e depois que os dados são processados, reinicio novamente o QTimer. O aplicativo deve funcionar de tal maneira que, após uma atualização/atualização (durante essa atualização, o aplicativo não responde), o usuário deve ter tempo suficiente para continuar trabalhando no aplicativo, além de vendo os dados sendo atualizados. Consigo obter pausas aceitáveis ​​para o usuário trabalhar - em um cenário.

Mas em sistemas operacionais diferentes (RHEL 5.0 a RHEL 5.2) a situação é algo diferente. O cronômetro enlouquece e continua a disparar sem dar nenhuma pausa entre as atualizações sucessivas, entrando assim em um loop infinito. 3 segundos, mas por esse motivo parei e reiniciei o cronômetro durante o processamento..e a ​​mesma lógica funciona em um cenário, enquanto em outro não..O outro fato que observei é que quando ocorre esse disparo rápido do cronômetro, o tempo que a função de atualização leva para sair é muito pequeno, cerca de 300ms, então o início-parada do cronômetro que coloquei no início e fim desta função acontece nesse pequeno espaço de tempo..então, antes que o processamento real dos dados termine, há 3-4 inícios do cronômetro na fila aguardando para serem executados e, portanto, o problema do loop infinito piora a partir desse ponto para cada atualização sucessiva .

O importante a ser observado aqui é que, para o mesmo código em um sistema operacional, o tempo de atualização é de cerca de 4.000 ms (o tempo real de processamento necessário para a mesma quantidade de dados), enquanto para o outro sistema operacional é de 300 ms.

Talvez isso tenha algo a ver com bibliotecas mais recentes no sistema operacional atualizado ... mas não sei como depurá-lo porque não consigo obter nenhuma pista de por que isso está acontecendo dessa maneira ...talvez algo relacionado a pthreads tenha mudado entre os sistemas operacionais?

Então, minha dúvida é se existe alguma maneira de garantir que algum processamento em meu aplicativo seja cronometrado (e independente do sistema operacional) sem usar o QTimer, pois acho que o QTimer não é uma boa opção para conseguir o que desejo?

Que opção pode estar lá?pthreads ou tópicos Boost?qual seria melhor se eu usasse threads como alternativa? Mas como posso ter certeza de pelo menos um intervalo de 3 segundos entre atualizações sucessivas, não importa quanto tempo leve o processamento da atualização?

Por favor, ajude.

Obrigado.

Answer 1

Se eu estivesse tentando obter uma solução aceitável e de longo prazo, investigaria a atualização de sua exibição em um tópico separado.Nesse tópico, você pode pintar a exibição em uma imagem, atualizando quantas vezes desejar...embora você possa querer limitar o thread para que ele não ocupe todo o tempo de processamento disponível.Então, no thread da interface do usuário, você pode ler essa imagem e desenhá-la na tela.Isso poderia melhorar sua capacidade de resposta ao movimento panorâmico, já que você poderia exibir diferentes partes da imagem.Você pode atualizar a imagem a cada 3 segundos com base em um cronômetro (basta redesenhar a partir da fonte) ou pode fazer com que o outro thread emita um sinal sempre que os novos dados forem completamente atualizados.