I am using Qt 5.7 for a GUI application with a QProgressBar. I suspect that there might be a memory leak since memory usage increases during runtime for about 50MB/s. I could narrow down the problem to one line of code.
QProgressBar *pbarQuality;
...
int curQuality = data.getQuality();
if (curQuality < 0) {
curQuality = 0;
qWarning("Value set to 0. ");
}
if (curQuality > 100) {
curQuality = 100;
qWarning("Value set to 100. ");
}
ui.pbarQuality->setValue(curQuality); //The memory problem doesn't occur when this single line is commented out
The value of the QProgressBar(pbarQuality) is only for displaying. It isn't used anywhere else.
I find this a very strange behaviour. Am I missing something?
Here is the auto generated code by the Qt Designer:
pbarQuality = new QProgressBar(frame_5);
pbarQuality->setObjectName(QStringLiteral("pbarQuality"));
pbarQuality->setGeometry(QRect(10, 50, 130, 23));
pbarQuality->setValue(24);
Try replacing setValue by pbarQuality.update(); QCoreApplication::processEvents(); and see if that reproduces the problem. If it does, you're leveraging the nested event loop to keep the GUI responsive while your blocking code runs, and that's a bad thing. setValue calls processEvents as a naive way to work around broken user code. IMHO it's a dangerous favor. The only fix then is to unbreak your code and return control to the main event loop instead of blocking.
This answer shows how to avoid the effects of an image storm by leveraging the QImage's RAII behavior, and links to another answer that demonstrates free image scaling by leveraging OpenGL.
My application runs another thread besides the GUI thread which periodically(up to 60 times per second) sends information(images) to the GUI thread. I am doing some minor image editing (resizing) within the GUI thread. Turns out this takes too long in order to keep up with the data posted by the other thread. Consequentially the event queue gets bigger and bigger and so does the used RAM too.
Lesson learned: Be aware of the processing speed of the thread if the data gets posted periodically. Data processing needs to be done before new data is available.
Thanks to #KubaOber for giving me the hint.
Related
I have a UI application in Qt, i have a couple of functions that run large scale SQL queries that returns thousands of results.
when the button that runs this query is clicked the UI windows just instantly goes to 'not responding' however i can see from console outputs that everything is still actually running in the background. As soon as the function ends the data is presented as expected and the UI is responding again and fully functional.
i know this is due to the fact that the function is looping thousands of times due to the large number of results, but i was hoping that i could have just put in a loading bar that progresses as the search does instead of just locking up the window making it look like the program has crashed. AFAIK i dont have memory leaks so does anyone have any suggestions?
oh also im thinking its not memory leaks because when i click that button task manager shows only a couple of MB of memory being used for this process and processor is by no means maxing out either
In an application, there's one thread that's responsible for handling UI events, messages, whatever you want to call them. Suppose that you have a button click event. As long as you don't return from the callback function, no other UI event can be triggered (repainting, updating, etc) and UI becomes unresponsive.
To mitigate this, you should considering performing time consuming tasks in a separate thread and once they're complete, update UI accordingly. If you need to block UI while the task is processed, you can disable your controls, display a pop up progress bar, whatever, but keep the UI thread relatively unoccupied to avoid "not responding" problem.
A simpler solution than to use threads is to use QCoreApplication::processEvents(). If your code is something like this:
void slowFunction()
{
lostOfResults = makeSqlQuery(...); // quite fast
for (r in lostOfResults)
doSomethingWithResult(r); // one call is quite fast
}
If one SQL query or one doSomethingWithResult() doesn't take too much time, you can process pending events using QCoreApplication::processEvents() like this:
void slowFunction()
{
lostOfResults = makeSqlQuery(...);
for (r in lostOfResults)
{
doSomethingWithResult(r);
QCoreApplication::processEvents();
}
}
Now the GUI events are processed and the program doesn't freeze. But if the SQL query alone takes a lot of time (several seconds) this doesn't help. Then you should consider separate thread.
I have a GUI app that I am creating with wxWidgets. As part of the functionality, I have to run "tasks" simultaneously with manipulation of the GUI window. For example, I may run the code:
long currentTime = wxGetLocalTime();
long stopTime = wxGetLocalTime() + 3;
while (wxGetLocalTime() != stopTime) {}
wxMessageBox("DONE IN APP");
For the duration of those 3 seconds, my application would essentially be frozen until the wxMessageBox is shown. Is there a way to have this run in the background without the use of multiple threads? It creates problems for the application that I've developing.
I was wondering if there are some types of event handling that could be used. Any sort of help is greatly appreciated.
There are 3 ways to run time-consuming tasks in GUI wx applications:
By far the most preferred is to use a different thread. The explanation of the application being "very GUI intensive" really doesn't make any sense to me, I think you should seriously reconsider your program design if its GUI intensity (whatever it is) prevents you from using background worker threads. If you do use this approach, it's pretty simple but pay special attention to the thread/program termination issues. In particular, you will need to either wait for the thread to finish (acceptable if it doesn't take a long time to run) or cancel it explicitly before exiting the program.
Use EVT_IDLE event to perform your task whenever there are no other events to process. This is not too bad for small tasks which can be broken in small enough pieces as you need to be able to resume processing in your handler. Don't forget to call event.RequestMore() to continue getting idle events even when nothing is happening otherwise.
The worst and most dangerous was is to call wxYield() as suggested by another answer. This can seem simple initially but you will regret doing it later because this can create extremely difficult to debug reentrancy problems in your code. If you do use it, you need to guard against reentrancy everywhere yourself and you should really understand what exactly this function does.
Try this:
long currentTime = wxGetLocalTime();
long stopTime = wxGetLocalTime() + 3;
while (wxGetLocalTime() != stopTime) {
wxYield();
}
wxMessageBox("DONE IN APP");
I know this is late to the game, but...
I've successfully used the EVT_IDLE method for YEARS (back in the 90's with Motif originally). The main idea is to break your task up into small pieces, where each piece calls the next piece (think linked-list). The mechanism to do this is using the CallAfter() method (using C++, of course). You just "CallAfter()" as the last step in the piece and that will allow the GUI main loop to run another iteration and possibly update GUI elements and such before calling your next piece. Just remember to keep the pieces small.
Using a background thread is really nice, but can be trickier than you imagine... eventually. As long as you know the data you're working on in the background won't be touched/viewed by anything else, you're OK. If you know this is the case, then that is the way to go. This method allows the GUI to remain fully responsive during background calculations (resizing/moving the window, etc.)
In either case, just don't forget to desensitize appropriate GUI elements as the first step so you won't accidentally launch the same background task multiple times (for example, accidentally clicking a push button multiple times in succession that launches the background thread).
Got really stuck, need some advise or real examples.
1) I have boost::thread vector producer thread (data arrives fast ~ 100 samples per second)
2) I want QMathGL to paint data as it arrives
3) I don't want my Qt gui freeze
I tried to move QMathGL::update() to separate thread - Qt argues that QPixmap not allowed in separate thread.
What should i try, Without modifying QMathGL?
Only thing comes in mind to repaint on timer (fps?), but i don't like this solution, please tell me if i am wrong.
I would strongly advise to go with a timer. Repaint operations are costly and I would assume that no user could realistically process more then 10 printed vectors a second. So I can't see a real benefit for the end user, apart from maybe that the display is updated more "smoothly" and entry for entry. But you could achieve these effects far easier with animations ;)
When repainting with every data change, you get the annoying behaviour you describe. Working around that is (imho) not worth the trouble.
I´ve also come along a similar problem sometimes.
The usual resolution i used is to buffer the data and repainting on a timer. This goes along the line of this (Pseudo Code) :
void Widget::OnNewData(void *dataSample)
{
this->threadSafebuffer->appendData(dataSample);
}
void Widget::OnTimeout()
{
DataBuffer renderBatch = this->threadSafebuffer->interlockedExchange();
/* Do UI updates according to renderBatch */
}
This assumes that OnNewData is called on a background thread. The OnTimeout is called from a QTimer on the UI-EventLoop. To prevent contention it justs does an interlocked exchange of the current buffer pointer with a second buffer. So no heavy synchronization (e.g. Mutext/Semaphore) is needed.
This will only work if the amount of work to do for rendering a renderBatch is less than the timeout.
Am I correct in thinking that the QGraphics* classes are not thread-safe? I am porting an old app to Qt and in the process attempting to make it multi-threaded too. I looked at the update code and I see no locks whatsoever.
I started off right, all my processing is done in a set of worker threads so that the GUI does not have to block. But as soon as I come to display my visual representation the whole thing falls down like a pack of cards as the update code attempts to read from the buffer the other thread is writing to.
Here is my test case:
Create a bunch of ellipse objects
Create a thread and pass it the scene pointer
In a loop modify any setting on any object in the scene.
Test function:
bool CBasicDocument::Update( float fTimeStep )
{
const QList<QGraphicsItem*> tObjects = items();
for( QList<QGraphicsItem*>::const_iterator tIter = tObjects.constBegin();
tIter != tObjects.constEnd();
++tIter )
{
QGraphicsEllipseItem* pElipse = (QGraphicsEllipseItem*)(*tIter);
if( pElipse )
{
pElipse->setPen( QPen( QColor( (int)(255.0f * sinf( fTimeStep )), (int)(255.0f * cosf( fTimeStep )), (int)(255.0f * sinf( fTimeStep )) ) ) );
}
}
return true;
}
I have been thinking about ways I can fix this and none of them are particularly pretty.
Ideally what I want to happen is when I change a setting on an object it is buffered until the next render call, but for the time being I'll settle with it not crashing!
At the moment I have four options:
Double buffer the whole scene maintaining two scene graphs in lockstep (one rendering, one updating). This is how our multithreaded game engine works. This is horrible here though because it will require double the CPU time and double the memory. Not to mention the logistics of maintaining both scene graphs.
Modify QGraphics* to be thread safe as above. This is probably the most practical approach but it will be a lot of work to get it done.
Push modifications to the scene into a queue and process them from the main thread.
Throw multithreading to the wind for the time being and just let my app stall when the document updates. (Not pretty given the data size for some documents)
None of them are particularly appealing and all require a massive amount of work.
Does anybody have any ideas or attempted multithreading QGraphicsScene before?
Cheers
I've always read it's a better idea to have all the GUI work happen in the main thread, no matter you're using GTK or Qt or else.
In your case I would go for option 2.
Modifying Qt's code to put locks here and there is the worst thing to do ihmo as you won't be able to sync your modified Qt with upstream without a significant amount of work.
I notice in your test function that you are already casting (using c-style casts, at that) the QGraphicsItem to a QGraphicsEllipseItem. If you only use a certain number of item types, it might be easier to subclass those types, and provide the thread-safe functions in those subclasses. Then cast down to those subclasses, and call what you want to from the other thread. They can handle buffering the changes, or mutex locking, or whatever you want to do for those changes.
An alternative would be to have one mutex, and each thread locks that when processing. This would likely slow you down a lot as you wait for the mutex to become available. You could also maintain a map of items->mutexes somewhere that both threads can get to, and each thread locks the mutex for the item it is working on while it is working with it. This would be simpler to layer in if you think the subclassing option would be too complex.
I have a loop to take in images from a high speed framegrabbger at 250fps.
/** Loop processes 250 video frames per second **/
while(1){
AcquireFrame();
DoProcessing();
TakeAction();
}
At the same time, I would like the user to be able to monitor what is going on. The user only needs to see images at around 30 fps (or less). How do I set up a second thread that displays the current frame every so often?
Thread(){
cvShowImage();
Wait(30); /** Wait for 30 ms **/
}
I am on Windows on a quad core Intel machine using MinGW, gcc and OpenCV 1.1. The main criteria is that the display thread must take as little time away from my main processing loop as possible. Every millisecond counts.
I have tried using CreateThread() to create a new thread with cvShowImage() and cvWaitKey() but apparently those functions are not threadsafe.
I am considering using OpenMP, but some people report problems with OpenMP and OpenCV. I also am considering trying to use DirectX directDraw because apparently it is very fast. but it looks complicated and evidentally there are problems using Windows DLL's with MinGw.
Which of these avenues would be the best place to start?
Ok. So embarrassingly my question is also its own answer.
Using CreateThread(), CvShowImage() and CvWaitKey() as described in my question actually works-- contrary to some postings on the web which suggest otherwise.
In any event, I implemented something like this:
/** Global Variables **/
bool DispThreadHasFinished;
bool MainThreadHasFinished;
iplImage* myImg;
/** Main Loop that loops at >100fps **/
main() {
DispThreadHasFinished = FALSE;
MainThreadHasFinished = FALSE;
CreateThread(..,..,Thread,..);
while( IsTheUserDone() ) {
myImg=AcquireFrame();
DoProcessing();
TakeAction();
}
MainThreadHasFinished = TRUE;
while ( !DisplayThreadHasFinished ) {
CvWaitKey(100);
}
return;
}
/** Thread that displays image at ~30fps **/
Thread() {
while ( !MainThreadHasFinished ) {
cvShowImage(myImg);
cvWaitKey(30);
}
DispThreadHasFinished=TRUE;
return;
}
When I originally posted this question, my code was failing for unrelated reasons. I hope this helps!
Since the frame grabbing doesn't need to use the UI, I'd set up a secondary thread to handle the frame grabbing, and have the original thread that handles the UI display the sample frames. If you tried to display the frame currently be grabbed, you'd have to lock the data (which is generally fairly slow). To avoid that, I'd display a frame one (or possibly two) "behind" the one currently being grabbed, so there's no contention between grabbing and displaying the data. You'll still have to ensure that incrementing the current frame number is thread-safe, but that's pretty simple -- use InterlockedIncrement in the capture thread.
I'm sorry I can't give you a better answer right now, but it seems that your question is not about the structure of your program but rather about the tool you should use to implement multithreading. For this I would recommend Qt. I have been using Qt for a while but I'm just now getting into multithreading.
It seems to me that your best bet might be a QReadWriteLock. This allows you to read from an image but the reader thread will give up its lock when the writer thread comes along. In this case you could keep a copy of the image you last displayed and display it if the image is locked for writing.
Sorry again that I can't be more detailed but, like I said, I'm just getting into this as well. I'm basically trying to do the same thing that you are, but not nearly as fast :). Good luck!
I'm not sure why this happens, but I've added a cvWaitKey after every cvShowImage and the picture was displayed properly.
cvShowImage(myImage);
cvWaitKey(1);