Problema de disparo de QTimer en QGIS (Quantum GIS)

Question

He participado en la creación de una aplicación QGIS personalizada en la que los datos en vivo se mostrarán en el visor de la aplicación.

El IPC que se utiliza son las colas de mensajes de Unix.

Los datos deben actualizarse en un intervalo especificado, por ejemplo, 3 segundos.

Ahora, el problema al que me enfrento es que el procesamiento de los datos que se mostrarán lleva más de 3 segundos, por lo que lo que he hecho es que antes de que la aplicación comience a procesar los datos para la próxima actualización, la actualización QTimer se detiene y, una vez procesados ??los datos, vuelvo a reiniciar el QTimer. La aplicación debería funcionar de tal manera que después de una actualización / actualización (durante esta actualización la aplicación no responda) el usuario debería tener tiempo suficiente para continuar trabajando en el aplicación aparte de ver la actualización de los datos. Puedo obtener pausas aceptables para que el usuario trabaje, en un escenario.

Pero en sistemas operativos diferentes (RHEL 5.0 a RHEL 5.2) la situación es algo diferente. El temporizador se vuelve loco y continúa disparando sin hacer ninguna pausa por las actualizaciones sucesivas, por lo que entra en un bucle infinito. Manejando estos datos de actualización definitivamente toma más de 3 segundos, pero por esa misma razón, detuve, reinicié el temporizador mientras procesaba ... y la misma lógica funciona en un escenario, mientras que en otro no. El otro hecho que he observado es que cuando este disparo rápido del tiempo del temporizador, el tiempo que tarda la función de actualización en salir es muy pequeño, aproximadamente 300 ms, por lo que el inicio-parada del temporizador que he colocado al inicio y al final de esta función ocurre en ese pequeño tiempo ... antes finaliza el procesamiento real de los datos, hay 3-4 inicios del temporizador en la cola en espera de ser ejecutados y, por lo tanto, el problema de bucle infinito empeora a partir de ese punto para cada actualización sucesiva.

Lo importante a tener en cuenta aquí es que para el mismo código en un sistema operativo, el tiempo de actualización se muestra en torno a los 4000 ms (el tiempo de procesamiento real utilizado para la misma cantidad de datos) mientras que para el otro sistema operativo es de 300 ms.

Tal vez esto tenga algo que ver con las nuevas bibliotecas en el sistema operativo actualizado ... pero no sé cómo depurarlo porque no puedo obtener ninguna pista de por qué está sucediendo como tal ... tal vez algo relacionado con pthreads ha cambiado b / w los sistemas operativos ??

Por lo tanto, mi consulta es que hay alguna forma de asegurar que se procese algo de procesamiento en mi aplicación (y que es independiente del sistema operativo) sin usar QTimer, ya que creo que QTimer no es una buena opción para lograr lo que yo quieres ??

¿Qué opción puede estar allí? pthreads o hilos de impulso? ¿cuál sería mejor si tuviera que usar hilos como una alternativa? Pero, ¿cómo puedo asegurarme de que haya al menos un intervalo de 3 segundos en b / n actualizaciones sucesivas sin importar cuánto tiempo tome el proceso de actualización?

Ayuda amable.

Gracias.

Answer 1

Si intentara obtener una solución aceptable a largo plazo, investigaría la actualización de su pantalla en un hilo separado. En ese hilo, podría pintar la pantalla a una imagen, actualizándola tantas veces como lo desee ... aunque es posible que desee estrangular el hilo para que no tome todo el tiempo de procesamiento disponible. Luego, en el hilo de la interfaz de usuario, puede leer esa imagen y dibujarla en la pantalla. Eso podría mejorar su capacidad de respuesta a la panorámica, ya que podría mostrar diferentes partes de la imagen. Puede actualizar la imagen cada 3 segundos en función de un temporizador (simplemente volver a dibujar desde la fuente), o puede hacer que el otro hilo emita una señal cada vez que los nuevos datos se actualicen por completo.