Resizing mainwindow using resizeEvent works very slow

? Offline

Well, I don't know how readPosition() is implemented. But in general if the data in the file is static you should read that file only once (for example when your application is starting). To me it looks like you're doing it each time drawPath() is called.

so here is my readPosition()

void DrawPath::readPosition(QString inFile_)
{
    //read from text file
    QFile file(inFile_);
    if(!file.open(QIODevice::ReadOnly | QIODevice::Text)){
        qDebug() << "error: unable to open...";
    }

    QTextStream in(&file);

    while(!in.atEnd()){
        QString lineData = in.readLine();
        QStringList listData = lineData.split("\t");

        someX << listData[4].toFloat();
        someY << listData[5].toFloat();
    }

    for(int i = 0; i < someX.size()-1; i++){

        //collect vector data into coordinate(x,y)
        xyPos.setX(someX[i]);
        xyPos.setY(someY[i]);

        //create vector of coordinate(x, y)
        xyPosVector.append(xyPos);
    }

    qDebug() << "Successfully loaded!";

    file.close();
}

At the moment, the data is static but it will be updated maybe daily for the complete version of the program. I would like to know if it's gonna be lagged.

kshegunov

@soloespresso

Edit: the program will be used for a realtime (x, y) calculation so I need a fast working resize window.

If you want a "realtime" behavior, then thread the IO! It's not the QWidget::resizeEvent's job to read files and do (complicated) calculations. In your worker thread or main thread (by means of scheduling, but it's better to actually thread the operation) do the calculations and update a couple of fields. Then in the resize or paint events do the bare minimum of setting the geometry or painting the data. Events are queued and no event will be processed if the last one hasn't finished, so a slow resize event processing will cause your application to hang, not update widgets and not respond to user input, not process sockets or timers!

DrawPath::readPosition is heavy (it reads a whole file), as @jsulm already suspected, and you do that in the event function(s), so everything is waiting for the IO to complete.

Kind regards.

jsulm

@soloespresso readPosition() does not set someVector!
If the change frequency of the file is so low then you should not read it all the time - it's just wasted time. You can use QFileSystemWatcher class to detect changes in this file and then reread it.

? Offline

@kshegunov said:

If you want a "realtime" behavior, then thread the IO!

And ow can I do that?

I have tried calling only the function to calculate (x, y) without calling drawPath() in resizeEvent() something like this

path->calculatedXY(someVector, width, height);

but it gives me Runtime Error and "index out of range" for the vector used in that function.

kshegunov

@soloespresso said:

And ow can I do that?

Look here for an introduction.

but it gives me Runtime Error and "index out of range" for the vector used in that function.

See @jsulm's explanation as to why this is happening.
Additionally your for loop is wrong:

for (int i = 0; i < someX.size()-1; i++)  {

this skips the last element in the vector.

Kind regards.

? Offline

@jsulm

@jsulm said:

@soloespresso readPosition() does not set someVector!

I have some other functions in between. The readPosition() I posted is to give an idea what readPosition() does which is extract the data and keep them in a vector.

If the change frequency of the file is so low then you should not read it all the time - it's just wasted time. You can use QFileSystemWatcher class to detect changes in this file and then reread it.

OK, I will take a look on that.

? Offline

@kshegunov said:

@soloespresso said:

And ow can I do that?

Look here for an introduction.

Ok, I will take a look.

but it gives me Runtime Error and "index out of range" for the vector used in that function.

See @jsulm's explanation as to why this is happening.
Additionally your for loop is wrong:
for (int i = 0; i < someX.size()-1; i++)  {
this skips the last element in the vector.

Kind regards.

Right!!! I didn't see it. Thank you.

? Offline

for (int i = 0; i < someX.size()-1; i++)  {

fix this but still Runtime Error and "index out of range".

I will check QFileSystemWatcher and thread after.

kshegunov

@soloespresso

fix this but still Runtime Error and "index out of range".

This hasn't anything to do with your error, it was just an observation. As to the assertion (which I'm assuming your code is failing), you should track that in the debugger.

? Offline

@kshegunov said:

@soloespresso

fix this but still Runtime Error and "index out of range".

This hasn't anything to do with your error, it was just an observation. As to the assertion (which I'm assuming your code is failing), you should track that in the debugger.

So let me make sure if what I am doing is ok for Qt.
I have drawPath() in QWidget.

void DrawPath::drawPath(QString inFile, QString outFile, float width, float height)
{
    readPosition(inFile);
    calculatedXY(someVector, width, height);
    writePosition(outFile, latLongPointVector);
}

Can I call calculatedXY(someVector, width, height); outside drawPath() in resizeEvent() like this?

void MainWindow::resizeEvent(QResizeEvent *event)
{

    //scaled window size
    scaledWidth = double(event->size().width())/360.0;
    scaledHeight = double(event->size().height())/180.0;

    //QString inFile = ":/input.txt";
    //QString outFile = "output.txt";

    //set label window size
    ui->label->setGeometry(0, 0, 360*scaledWidth, 180*scaledHeight);

    //set draworbit window size
    //path->drawPath(inFile, outFile, scaledWidth, scaledHeight);
    path->calculatedXY(someVector, scaledWidth, scaledHeight);
    path->setGeometry(0, 0, 360*scaledWidth, 180*scaledHeight);
}

kshegunov

@soloespresso
No one is preventing you from calling calculatedXY(), but if it's a good design choice really depends what that function actually does.

? Offline

@kshegunov said:

@soloespresso
No one is preventing you from calling calculatedXY(), but if it's a good design choice really depends what that function actually does.

Thank you for the confirmation.
Because calling drawPath() will call readPosition(), calculatedXY() and writePosition(), calling calculatedXY() directly will prevent resizeEvent() to reread the text file.

But this give me that Runtime Error and "index out of range" which I will debug later.

Now the problem is how to draw the line? I use paintEvent() to draw a line and the function is called when drawPath() is called.

jsulm

"Now the problem is how to draw the line?" - what is the problem with that? When paintEvent() is called you draw the line.

? Offline

@jsulm said:

"Now the problem is how to draw the line?" - what is the problem with that? When paintEvent() is called you draw the line.

But then it means paintEvent() is called directly in resizeEvent()?
Is something like the code below possible?

void MainWindow::resizeEvent(QResizeEvent *event)
{

    //scaled window size
    scaledWidth = double(event->size().width())/360.0;
    scaledHeight = double(event->size().height())/180.0;

    //QString inFile = ":/input.txt";
    //QString outFile = "output.txt";

    //set label window size
    ui->label->setGeometry(0, 0, 360*scaledWidth, 180*scaledHeight);

    //set draworbit window size
    //path->drawPath(inFile, outFile, scaledWidth, scaledHeight);
    path->calculatedXY(someVector, scaledWidth, scaledHeight);
    path->paintEvent();
    path->setGeometry(0, 0, 360*scaledWidth, 180*scaledHeight);
}

jsulm

No, paintEvent() is called by Qt whenever a repaint is needed.
For example it is called after resizing a widget (as stated in documentation).

? Offline

@jsulm ok. sorry for a dumb question. I have tried it before but it didn't work so I wasn't sure if I understand how it works correctly.

So I tried calling the calculatedXY() directly in resizeEvent(), the line is drawn but not scaled when window is maximized. It is scaled only when I call the whole drawPath().

However, even calling directly calculatedXY() in resizeEvent(), the lag persists. Still appx 4 secs delay....

I have tried changing the size of the background img, even removed it, but still get the same result. I have no idea what could be a reason....