Home/ Questions/Q 8935379
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T09:58:22+00:00

As stated clearly in the documentation, Qt GUI must be accessed from main thread

  • 0

As stated clearly in the documentation, Qt GUI must be accessed from main thread only. For complex app with multiple large and busy tables, this can be a bottleneck just from all the font-size text metrics calculations Qt likes to do. The only alternative I can think of is multi-tasking with separate processes. The tables are currently about as fast as you can get, custom model that is direct-mapped to a cache that is fed from another thread using dataChanged() calls on the most conservative set of changed cells. I’ve already profiled with vTune, 70% of the app time is now in Qt rendering code. Any suggestions?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I havn’t used QT, but accessing GUI from only one thread (the GUI thread) is a known matter in almost any GUI I’m familiar with. I used 2 solutions for this case, of which I prefer the first one:

    1) Your form will update the GUI (table, in this case) at timer intervals. The timer is activated on the GUI thread’s events. At those timer events you read the data from global vars and update your table. The global vars can be updated by as many threads as you wish. You might need to synch (semaphores, for examples) the access to the global vars.

    2) In many GUI APIs threads can update the GUI by handing the GUI thread a function (or an object) and ask it to execute it ASAP on its context. The calling thread meanwhile blocks, until the GUI fulfilled the action. I can recall three such functions – Invoke, InvokeLater from Java and C#, or wx.CallAfter of wxPython.

    • 0