添加链接
link之家
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I'm doing work where timing is extremely important, and have a question about the behavior of processEvents(). When I call processEvents(), is it run on a seperate thread/process, such that it may still be running as more of my code is executed?

If not, is there any chance that my code continues executing after processEvents() but before all the pixels on my monitor are updated to the newest scene (perhaps because the operating system handles pixel drawing)? Pseudo code below

app = QtWidgets.QApplication(sys.argv)
window = MainWindow()
window.drawScene()
app.processEvents() #Force window to update to scene
print("Hi!") #Is there any chance of this being called before my screen's pixels are all set to the newest scene?

If the code after processEvents() does run before the screen's pixels are all updated, is there a way to guarantee that the screen is updated before continuing?

QCoreApplication::processEvents() runs in the same thread as you call it from, it does not use a seperate thread. It will process all events currently queued up in the event queue. If there is an event of type QEvent::Paint in the queue, it will trigger a repaint of the window. Your drawScene() will probably put a paint event into the event queue, by directly or indirectly calling QWidget::update().

So yes, a call to processEvents() will finish a pending repaint and only return once the repaint event has been processed.

FWIW, QProgressDialog::setValue() internally calls processEvents() to make sure the progress bar is updated, so this has to work there as well.

The only reason I can think of that would cause the pixels not to be shown is the platform-specific code in the so-called platform plugin doing something asynchronous when repainting. One would need to double-check the platform plugin code of the OS you are using to be absolutely sure.

This actually seems to be the case on X11, which is async. Check the docs for QTest::qWaitForWindowExposed - internally it calls processEvents() in a loop, until QWindow::isExposed() returns true. So at least for initially showing windows, you need to run processEvents() in a loop to make sure the window is actually shown. I do not know if the same is needed for repainting. See the section "Visibility and Windowing System Exposure" in the docs of QWindow for more details.

What do you mean by run processEvents() in a loop? It doesn't return anything as far as I can tell – yellowedhare Jun 6, 2017 at 17:52 I think the code explains it better than I could - look at the code of qWaitForWindowExposed at code.woboq.org/qt5/qtbase/src/testlib/… – Thomas McGuire Jun 6, 2017 at 17:55

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.