QGIS(Quantum GIS) 中的 QTimer 触发问题
我参与了构建一个自定义的 QGIS 应用程序，其中实时数据将显示在应用程序的查看器上。
使用的IPC是unix消息队列。
数据以指定的间隔（例如 3 秒）刷新。
现在我面临的问题是处理要显示的数据需要超过3秒，所以我所做的是在应用程序开始处理下一次更新的数据之前，刷新QTimer停止处理数据后，我再次重新启动 QTimer。应用程序应该以这样的方式工作：更新/刷新后（在此刷新期间，应用程序没有响应），用户应该有足够的时间继续使用应用程序，除了看到数据正在更新。在一种情况下，我能够为用户工作提供可接受的暂停。
但在不同的操作系统（RHEL 5.0 到 RHEL 5.2）上，情况有所不同。计时器会疯狂并继续触发，而不会在连续更新中给出任何暂停，从而进入无限循环。处理此更新数据肯定需要比3秒，但正是因为这个原因，我在处理时停止重新启动了计时器。相同的逻辑在一种情况下有效，而在另一种情况下则不然。我观察到的另一个事实是，当计时器快速启动时发生刷新功能退出所需的时间非常短，大约 300 毫秒，因此我在该功能的开始和结束处放置的计时器的启动停止发生在这么短的时间内......所以在实际处理之前数据完成后，队列中有 3-4 个计时器启动等待执行，因此从那时起，每次连续更新，无限循环问题都会变得更糟。
这里需要注意的重要一点是，对于一个操作系统中的相同代码，刷新时间显示为 4000 毫秒左右（相同数据量的实际处理时间），而对于另一个操作系统，刷新时间为 300 毫秒。
也许这与更新的操作系统上的新库有关..但我不知道如何调试它，因为我无法得到任何线索为什么会发生这种情况...也许与 pthreads 相关的东西已经改变了黑白操作系统？
所以，我的疑问是，有什么方法可以确保我的应用程序中的某些处理是定时的（并且独立于操作系统）而不使用 QTimer，因为我认为 QTimer 不是实现我想要的效果的好选择？
有什么选择可以吗？ pthreads 还是 Boost 线程？如果我使用线程作为替代方案，哪一个会更好？但是，无论更新处理需要多长时间，我如何确保黑白连续更新至少有 3 秒的间隙？
请帮忙。
谢谢。
I have been involved in building a custum QGIS application in which live data is to be shown on the viewer of the application.
The IPC being used is unix message queues.
The data is to be refreshed at a specified interval say, 3 seconds.
Now the problem that i am facing is that the processing of the data which is to be shown is taking more than 3 seconds,so what i have done is that before the app starts to process data for the next update,the refresh QTimer is stopped and after the data is processed i again restart the QTimer.The app should work in such a way that after an update/refresh(during this refresh the app goes unresponsive) the user should get ample time to continue to work on the app apart from seeing the data being updated.I am able to get acceptable pauses for the user to work-- in one scenario.
But on different OS(RHEL 5.0 to RHEL 5.2) the situation is something different.The timer goes wild and continues to fire without giving any pauses b/w the successive updates thus going into an infinite loop.Handling this update data definitely takes longer than 3 sec,but for that very reason i have stopped-restarted the timer while processing..and the same logic works in one scenario while in other it doesnt.. The other fact that i have observed is that when this quick firing of the timer happens the time taken by the refreshing function to exit is very small abt 300ms so the start-stop of the timer that i have placed at the start-and-end of this function happens in that small time..so before the actual processing of the data finishes,there are 3-4 starts of the timer in queue waiting to be executed and thus the infinite looping problem gets worse from that point for every successive update.
The important thing to note here is that for the same code in one OS the refresh time is shown to be as around 4000ms(the actual processing time taken for the same amount of data) while for the other OS its 300ms.
Maybe this has something to do with newer libs on the updated OS..but I dont know how to debug it because i am not able to get any clues why its happening as such... maybe something related to pthreads has changed b/w the OSs??
So, my query is that is there any way that will assure that some processing in my app is timerised(and which is independent of the OS) without using QTimer as i think that QTimer is not a good option to achieve what i want??
What option can be there?? pthreads or Boost threads? which one would be better if i am to use threads as an alternate??But how can i make sure atleast a 3 second gap b/w successive updates no matter how long the update processing takes?
Kindly help.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我试图获得一个可接受的长期解决方案，我会研究在单独的线程中更新您的显示。在该线程中，您可以将显示绘制到图像上，根据需要随时更新...尽管您可能希望限制线程，这样就不会占用所有可用的处理时间。然后在 UI 线程中，您可以读取该图像并将其绘制到屏幕上。这可以提高您对平移的响应能力，因为您可以显示图像的不同部分。您可以根据计时器每 3 秒更新一次图像（只需从源中重绘），或者您可以让另一个线程在新数据完全刷新时发出信号。
If I was trying to get an acceptable, longer-term solution, I would investigate updating your display in a separate thread. In that thread, you could paint the display to an image, updating as often as you desire... although you might want to throttle the thread so it doesn't take all of the processing time available. Then in the UI thread, you could read that image and draw it to screen. That could improve your responsiveness to panning, since you could be displaying different parts of the image. You could update the image every 3 seconds based on a timer (just redraw from the source), or you could have the other thread emit a signal whenever the new data is completely refreshed.