Don't repaint instantly after setVisble in Qt - qt

Question

I'm using QPushButton in my mineSweeping game.
After changing from easy mode to hard mode, the number of QPushButton is supposed to change from 9x9 to 30x16.
So, I add QPushButton with the largest number(which is of hard mode) to GridLayout in constructor of MainWindow.
btnArr = new QPushButton[HARD_WIDTH * HARD_HEIGHT]; // member element
int index = 0;
for (int i = 0; i < HARD_HEIGHT; ++i) {
for (int j = 0; j < HARD_WIDTH; ++j) {
ui->mainGrid->addWidget(&btnArr[index], i, j, 1, 1,
Qt::AlignCenter);
++index;
}
}
Then if the user change mode(e.g.: easy mode to hard mode), resetBtn(HARD_WIDTH, HARD_HEIGHT); will be called.
void MainWindow::resetBtn(const int width, const int height)
{
int index = 0;
for (int i = 0; i < HARD_HEIGHT; ++i) {
for (int j = 0; j < HARD_WIDTH; ++j) {
if (j < width && i < height) {
btnArr[index].setVisible(true);
} else {
btnArr[index].setVisible(false);
}
++index;
}
}
}
The problem is that it seems the widget repaints each time setVisible is called. So in the hard mode case, it will be called 30x16 times, which caused strange effect like this:
So how can I set the widget not repaint during this loop?
Thanks in advance.

Answer 1

I think that you are trying to solve the wrong problem. You shouldn't be updating the widgets like this. If you necessarily want to, then hiding the parent widget of the layout before the change and showing it again afterwards should work.
A better approach is to use QStackedWidget and have all the boards prepared initially. Switching to a different board is then simply a matter of switching the active widget.

Answer 2

The total number of QPushButton is really big: 30x16 = 480!!! I don't use to make people change their programming logic, but in this case I think that using QPushButtons is not the better approach. The layout must have a really bad time trying to move the objects as they are added, and perhaps you are reaching some internal limit in refresh time for the layout to be repainted.
What I would have done is a custom widget with a custom paintEvent method. There you can divide its width and height in the number of columns and rows that you wish and paint the cells with pixmaps as the game is played.
For the mouse interaction, the best would have been to override the mousePressEvent with a custom logic that calculates the mouse position in the grid and calls the corresponding methods or emits signals indicating the position of the event. Not very hard to code. You can also use the event->buttons() method to know which mouse button was pressed and emit different signals if you wish.
I don't use to answer telling that it is better to change your whole program, but in this case I think you are going "the hard way". I know this is not the kind of answer you are looking for, but consider this possibility.

Answer 3

You could try calling setUpdatesEnabled(false) on the parent widget before doing those "massive" changes, and re-enable it once all is done.

Answer 4

Maybe I'm wrong but as far as I know Qt doesn't render the widget right after setVisible() is called. Rendering happens as a result of a 'render' event, except if you call render() manually.
From the official Qt doc (http://qt-project.org/doc/qt-4.8/qwidget.html#paintEvent):
Qt also tries to speed up painting by merging multiple paint events
into one. When update() is called several times or the window system
sends several paint events, Qt merges these events into one event with
a larger region (see QRegion::united()). The repaint() function does
not permit this optimization, so we suggest using update() whenever
possible.
My instincts tell me that it's not a painting problem rather a layouting (not enough space to present every button in 'hard mode').
Also I think you shouldn't use Qt::AlignCenter when you add your buttons to the layout, it will try to centerize every button in the layout. You should rather centerize the parent widget of the layout (if you don't have one create one and centerize it) and set size-policies correctly (QWidget setSizePolicy).
But as #Mat suggested if this really is a painting problem you can use setUpdatesEnabled(false/true) (if setUpdatesEnabled solves your problem please accept #Mat 's solution)

Answer 5

Try to enabling/disabling instead of visible/invisible:
void MainWindow::resetBtn(const int width, const int height)
{
int index = 0;
for (int i = 0; i < HARD_HEIGHT; i++)
for (int j = 0; j < HARD_WIDTH; j++)
btnArr[index++].setEnabled(j < width && i < height);
}