Qt application won't repaint until first resize

[wysota]

It would be easier if you provided a minimal compilable example reproducing the problem.

[ComServant]

Knew someone was going to say that. =)
But if I could produce an example reproducing the problem, then I can fix it. My question is, how can I, in a complex project, isolate where the problem is? This step must be done before a minimal compilable can be created. Minimal compilable programs are usually for demonstrating flaws in Qt, where here I'm almost positive the flaw is in my own code.

This is partly a, "Does anyone recognize this particular problem, and can you point me at possible causes to save me dozens of hours of work?", and it's partly a question of, how do you debug large event-driven and signal-and-slot driven applications?

Normally, with single-threaded (hobbyist) videogame development, program execution is much more linear and easier for me to isolate the general area where the problem is. With widget-based applications, program flow is significantly more complex - jumping all over the place - and I don't have as much experience debugging that.

I was busy yesterday with other tasks, but today I'm starting to compare the diffs to find when (and hopefully where!) I introduced the problem. But if anyone has any advice of what to look for, or possible guesses at the cause, I'd greatly appreciate it.

[wysota]

But if I could produce an example reproducing the problem, then I can fix it.

Therefore you expect us to fix it just by knowing that "it doesn't work"?

My question is, how can I, in a complex project, isolate where the problem is?

There are two ways -- either start removing code from your non-working program until it starts working or start adding code to an empty program until it stops working.

Minimal compilable programs are usually for demonstrating flaws in Qt, where here I'm almost positive the flaw is in my own code.

No, minimal compilable examples are usually for finding flaws in your code by isolating code relevant to the issue. "Once you eliminate the impossible, whatever remains.. bla bla.. must be the truth".

Normally, with single-threaded (hobbyist) videogame development, program execution is much more linear and easier for me to isolate the general area where the problem is. With widget-based applications, program flow is significantly more complex - jumping all over the place - and I don't have as much experience debugging that.

Unless you introduced some threads yourself your program is still single-threaded. And since UI can operate only in the main thread, you can remove all your multi-threaded code and the problem will remain.

[ComServant]

I stand corrected; it is something within Qt (possibly). If I don't have Qt::FramelessWindowHint set on my main window, there isn't a problem. I can't reproduce it in a minimlistic program though - Qt::FramelessWindowHint alone isn't triggering it.

To hack around the problem, during startup I call this after an explicit call to QMainWindow's show() function:

this->setGeometry(this->geometry().adjusted(-1,-1,1,1));

this->setGeometry(this->geometry().adjusted(-1,-1,1,1));

To copy to clipboard, switch view to plain text mode 

This "fixes" my problem (hides it, more like). I'm not sure what the origin of the problem is. I don't know what part of my code, in combination with Qt::FramelessWindowHint, is triggering the behavior.

[wysota]

I really suggest you post some code. Without that there isn't much we can do. Right now I can only suggest installing an event filter on the application object and check whether paint events and other events you need are generated at all.