如何使用 CPP 在 qt 中制作 QTimer 作为空闲计时器

发布于 2025-01-10 18:28:26 字数 89 浏览 0 评论 0原文

我是 Qt 编程新手,我想让计时器成为空闲计时器。 问题是仅仅设置timer->start(0)是否会使定时器成为空闲定时器? 我怎么知道它是一个空闲计时器。

I am new to Qt programming, I want to make the timer an idle timer.
The question is whether just setting the timer->start(0) will make the timer an idle timer?
How can I know it's an idle timer.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

顾北清歌寒 2025-01-17 18:28:26

我想重复@Jeremy Friesner

在通用/多任务操作系统(例如通常运行的 Qt)上,您希望最大限度地减少应用程序的 CPU 使用率,以便任何其他可能正在运行的程序都可以使用这些剩余的 CPU 周期(或者在电池的情况下) - 供电设备,以便节省电池)。空闲时不断使用 CPU 周期的应用程序将被视为有错误。

快照任务管理器(testQTimer0.exe 运行时)

超时为 0 的应用程序永久占用(超过)一个核心并导致高货币消耗。


我们开始:间隔为 0 的 QTimer

#include <QtWidgets>

// main application

int main(int argc, char **argv)
{
  qDebug() << "Qt Version:" << QT_VERSION_STR;
  QApplication app(argc, argv);
  // setup GUI
  QWidget qWinMain;
  qWinMain.setWindowTitle("QTimer - timeout 0");
  QVBoxLayout qVBox;
  QLabel qLblText("Attention!\nThis may cause ventilation noise.");
  qVBox.addWidget(&qLblText);
  QLabel qLblI;
  qVBox.addWidget(&qLblI);
  qWinMain.setLayout(&qVBox);
  qWinMain.show();
  QTimer qTimer;
  qTimer.setInterval(0);
  ushort i = 0;
  // install signal handlers
  QObject::connect(&qTimer, &QTimer::timeout,
    [&]() {
      ++i;
      if (i) qLblI.setText(QString("i: %1").arg(i));
      else app.quit();
    });
  // runtime loop
  qTimer.start();
  return app.exec();
}

输出:

testQTimer0 的快照(GIF 动画)

间隔 0 使计时器立即到期。这意味着超时事件被附加到事件队列中。

因此,我希望队列永久充满超时和绘制事件(用于更新 qLblI),直到应用程序退出。


我过去曾经使用过这样的空闲事件(在我开始使用Qt之前)。我打算将 UI 事件循环与来自不同来源的轮询“事件”结合起来(并且不知道更好的替代方案)。因此,轮询功能为自己提供了超时选项。因此,poll 函数的调用会自行暂停进程,直到有事件进入或达到超时为止。最复杂的事情是以某种方式实现负载平衡,因为我试图在 UI 和其他事件源的处理之间平均分配可用时间。 (这对于 UI 事件与其他事件源同时高频地接近的情况很重要。)

但是,我怀疑这种摆弄在 Qt 中是否仍然有必要。对于这样的并发性,有更好的选择,例如在单独的线程中运行阻塞函数。

I'd like to repeat the concerns of @Jeremy Friesner:

On a general-purpose/multitasking OS (such as Qt usually runs under) you want to minimize your app's CPU usage so that any other programs that may be running can use those leftover CPU cycles (or in the case of a battery-powered device, so that the battery can be conserved). An app that is constantly using CPU cycles while idle would be considered buggy.

Snapshot of Task Manager (while testQTimer0.exe running)

An application with timeout 0 occupies (more than) one core permanently and causes a high currency consumption.


Here we go: a QTimer with interval 0:

#include <QtWidgets>

// main application

int main(int argc, char **argv)
{
  qDebug() << "Qt Version:" << QT_VERSION_STR;
  QApplication app(argc, argv);
  // setup GUI
  QWidget qWinMain;
  qWinMain.setWindowTitle("QTimer - timeout 0");
  QVBoxLayout qVBox;
  QLabel qLblText("Attention!\nThis may cause ventilation noise.");
  qVBox.addWidget(&qLblText);
  QLabel qLblI;
  qVBox.addWidget(&qLblI);
  qWinMain.setLayout(&qVBox);
  qWinMain.show();
  QTimer qTimer;
  qTimer.setInterval(0);
  ushort i = 0;
  // install signal handlers
  QObject::connect(&qTimer, &QTimer::timeout,
    [&]() {
      ++i;
      if (i) qLblI.setText(QString("i: %1").arg(i));
      else app.quit();
    });
  // runtime loop
  qTimer.start();
  return app.exec();
}

Output:

Snapshot of testQTimer0 (GIF Animation)

The interval 0 makes the timer immediately due. This means that a timeout event is appended to the event queue.

Thus, I expect the queue permanently filled with timeout and paint events (for update of qLblI) until the application exits.


I once used such an idle event in the past (before I started to use Qt). I intended to combine the UI event loop with polling "events" from a different source (and lacking any idea about a better alternative). Thereby, the polling function provided itself a time-out option. Thus, the call of the poll function suspended itself the process until either an event came in or the timeout was reached. The most intricate thing was to achieve somehow a load balancing as I tried to distribute the available time equally between the UI and the processing of the other event source. (This was important for the situation where UI events were approaching in high frequency concurrently with the other event source.)

However, I doubt that such a fiddling would be still necessary in Qt. For such a concurrency, there are better options e.g. to run a blocking function in a separate thread.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文