You are not logged in.

Dear visitor, welcome to QtForum.org. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

beckymcd

Beginner

  • "beckymcd" is female
  • "beckymcd" started this thread

Posts: 5

Location: Albuquerque, NM

Occupation: Software Engineer

  • Send private message

1

Monday, June 21st 2004, 4:44pm

Near Real Time Data Display

I am designing an application which will perform near time real-time display from a Reflective Memory Interface (RMI). I don't have any real hard and fast update rates to maintain. Bascially, I just need to display things as fast as I can. The types of display I will be doing are very basic and will include 2D plots as well as static text displays (status type information).

I've read where with QT (and most other GUI development tools) if you develop a multi-threaded application, only one thread can be dedicated to the GUI. This means that while there may be many "worker" threads, only one thread can perform GUI updates. Can someone confirm that this is indeed true?

If this is true, my question is which is better:

1) One multi-threaded application (with worker threads collecting data and one GUI thread updating multiple displays)
or
2) Several applications communicating through shared memory or some other IPC (threads, etc.)

Thanks,

Becky McDermott

  • "wysota" is male

Posts: 4,276

Location: Warsaw, POLAND

  • Send private message

2

Monday, June 21st 2004, 7:39pm

RE: Near Real Time Data Display

One multithreaded application is better. It's more consistent, and context switching between threads is faster than between processes. Also IPC needs switches to the system state, which also slows everything down - threads are often (like Posix Threads) run in userspace. Threads are sometimes called lightweight processes - the content of some structures doesn't need to be exchanged.

Beo

Beginner

Posts: 44

Location: Austria

  • Send private message

3

Tuesday, June 22nd 2004, 2:20pm

RE: Near Real Time Data Display

Quoted

Originally posted by beckymcd
I've read where with QT (and most other GUI development tools) if you develop a multi-threaded application, only one thread can be dedicated to the GUI. This means that while there may be many "worker" threads, only one thread can perform GUI updates. Can someone confirm that this is indeed true?

If this is true, my question is which is better:

1) One multi-threaded application (with worker threads collecting data and one GUI thread updating multiple displays)
or
2) Several applications communicating through shared memory or some other IPC (threads, etc.)


Hi,

first of all its true that only the main thread should access the gui, but that this is not a problem and how it is handled shows a little example I have made (see attachment).

It consists of 3 threads that are updating a textedit box each with different update periods individually. This could be your data, in this example it is just an integer that is incremented every update cycle.

The basic concept is that every thread reports the data to be displayed to the gui via customevents. This should be "near real time" as you call it. Well the event has to go threw the eventloop I guess the typical time for this is somewhere around 10ms~.

So no need to make several applications (ugly style ^^).

regards
Andy
Beo has attached the following file:
  • mthread.zip (2.8 kB - 82 times downloaded - latest: Aug 2nd 2017, 9:30am)
[QT] Beo