Threading a large program SOLVED

gpuckett54

I have a rather complicated application that I am having problems with. The application window is split into 2 halves. The left half is showing a moving map. The right half is showing the stream from a video camera. It was working fine when I was using QCamera to show the video. There were some issues I was struggling with so I converted the video to use QGraphicsVideoItem and QGraphicsScene. The new video works fine even when I have 3 or 4 different instances in split windows. But when I change the mapping application to use the new video player the video doesn't show anything and the movement of the map is extremely jerky. I am trying to determine if the application now has too much going on in the GUI thread or if the mapping code and the video code now are competing for the graphics resources.

Is there a way to determine for sure which is the problem?

I am assuming that the problem is too much in the GUI thread. I'm trying to decide the best solution for that. I don't need a lot of threads. I just need to offload processing from the GUI thread.

I was thinking one GUI thread and one worker thread. Is this the best approach?
Another option would be trying to run the functions in a different thread as necessary. But I have read there can be a lot of overhead in starting threads.
Is it possible to run different parts of a program in different threads and not have to start a thread each time a function needs to be executed?
Can I put a class in a separate thread and have it just sit and wait for a signal to cause a function to run and avoid thread starts by function? Or does code have to be always running to keep a thread active?

I appreciate any suggestions and feedback.

JKSH

Hi,

[quote]I am trying to determine if the application now has too much going on in the GUI thread or if the mapping code and the video code now are competing for the graphics resources.

Is there a way to determine for sure which is the problem?[/quote]Do some profiling to discover where your bottleneck is.

[quote author="gpuckett54" date="1407878169"]It was working fine when I was using QCamera to show the video. There were some issues I was struggling with so I converted the video to use QGraphicsVideoItem and QGraphicsScene.[/quote]I looked at your history and found http://qt-project.org/forums/viewthread/44642/ -- did you switch to QGraphicsScene for OpenGL functionality?

If so, note that QGraphicsScene does not use OpenGL.

[quote author="gpuckett54" date="1407878169"]I don't need a lot of threads. I just need to offload processing from the GUI thread.

I was thinking one GUI thread and one worker thread. Is this the best approach?[/quote]I'll need to know details of your application to be certain, but this sounds good. The simpler the better.

Note that your worker thread will not be able to read/write your GUI objects directly.

[quote author="gpuckett54" date="1407878169"]

Another option would be trying to run the functions in a different thread as necessary. But I have read there can be a lot of overhead in starting threads.
Is it possible to run different parts of a program in different threads and not have to start a thread each time a function needs to be executed?
Can I put a class in a separate thread and have it just sit and wait for a signal to cause a function to run and avoid thread starts by function? Or does code have to be always running to keep a thread active?[/quote]What you are looking for is a Worker QObject. See the first example in the "QThread documentation":http://qt-project.org/doc/qt-5/qthread.html

Basically, the worker object sits idly in the thread, not consuming any CPU resources until it receives a signal, like you described. Furthermore, that thread is permanent so you don't have to keep starting and stopping threads.

gpuckett54

I tried profiling and did not understand it a bit. I have done a lot of profiling in Java and found it very useful. It gave me details down to the method level and was very beneficial. I have tried two different profiling tools and got nothing like that.

Thank you for the info regarding threads. I am still learning about threads in C++ and Qt. I wasn't sure what would happen if there was no activity in a thread. I can make good use of that. With regards to the mapping side I think most of it can go in a separate thread now that I know it can sit idle. There is only a very small part that needs to be in the GUI thread. I can use signals to move generated information to the GUI.

I did switch to QGraphicsScene. Yes I did make the assumption that it was for OpenGL. But my main reason for doing that was because the mapping side is using QGraphicsScene and I was having complications with overlaying other QWidgets over the window. They don't display the same. Now that both side are using the same process I am hopeful this issue will be resolved. However it has caused this new problem.

The two forum threads have sort of merged into the same issue. I will close the other one to avoid complicating the matter. I really appreciate the responses. It is proving to be immense help to me.

I have a couple days of work to implement the changes discussed here and on the other thread. If anyone has further suggestions I would really appreciate it. Otherwise I will report back once I have made further progress.

JKSH

You're welcome. Post back when you have more news.

All the best!

gpuckett54

Any time I tried to connect the video directly to the widget the application did not work. So i created a separate thread that interfaces with the camera, capturing an image 20 times a second and passes the image to the UI thread via a signal. The UI thread simply updates the image which is a pixmap in a QGraphicsScene. It now works great.