QProgressBar has rendering errors or does not render at all

JonB

@YuXin
You have no idea/guarantee what number QDateTime::currentMSecsSinceEpoch() will return each time (and hence whether it will be odd or even always/never/sometimes), you cannot rely on that even matching a QTimer event in real time. [With your choice of startTimer(50); it's likely to be either always true or always false, I would have thought. At least startTimer(49) would more likely alternate.] Just saying, leave it at that.

YuXin

@JonB The timing of the startTimer does not affect the issue. Regardless of how it is adjusted, the problem can still be reproduced. Even if it is increased tenfold to 500, the issue persists—it's just that a shorter interval allows the problem to occur more quickly.

Additionally, the purpose of this if statement is exactly as you assumed: to randomly trigger setValue , rather than being aligned with the 50-interval setting.

JonB

@YuXin said in QProgressBar has rendering errors or does not render at all:

The timing of the startTimer does not affect the issue.

In principle an odd number is more likely to trigger QDateTime::currentMSecsSinceEpoch() % 2 being true on alternates than always being either true or false.

the purpose of this if statement is exactly as you assumed: to randomly trigger setValue

Exactly. And for that you would be much better off using a random number than your potentially-deterministic QDateTime::currentMSecsSinceEpoch() % 2 .

Anyway, I am sorry if we digressed. I intended this to be a brief comment, especially for posting for others to reproduce.

SGaist

Hi,

Which version of Qt are you using ?
On which OS ?

YuXin

@SGaist This question has been answered in the page.

SGaist

@YuXin Sorry, I missed that line.

Could you test with a more recent version of Qt ?

One small note: you are using a pretty large range which means that you won't necessarily see the painting done immediately. While it's likely unrelated to the issue at hand, it adds an unnecessary delay to test your issue.

YuXin

@SGaist The fact that the same issue occurred during the testing of version 6.9.0 clearly indicates that upgrading the version is useless. I also tested the currently latest version, 6.10, and the result is that the same problem persists.

hskoglund

Hi, it seems you have a race condition, i.e. the graphics effect and the progress bar are fighting each other, and currently the graphics effect is winning.

Try giving the progress bar the upper hand by telling it to repaint, say like this:

...
// add a repaint call
void timerEvent(QTimerEvent* event) override {
        if (QDateTime::currentMSecsSinceEpoch() % 2)
        {
            pb.setValue(pb.value() + 1);//If the number 1 is changed to a number greater than or equal to 20, it will work normally
            pb.repaint();
        }
        static int counter = 1;
        text.setText(QString::number(counter++));
}
...

SGaist

@YuXin said in QProgressBar has rendering errors or does not render at all:

@SGaist The fact that the same issue occurred during the testing of version 6.9.0 clearly indicates that upgrading the version is useless. I also tested the currently latest version, 6.10, and the result is that the same problem persists.

No, it only indicates that there's an issue with the version you tested against.

Since it still happens with 6.10, then there's indeed something to investigate.

Try the suggestion of @hskoglund and if does not improve the situation, then check the bug report system and if you don't find anything there, please open a new ticket providing your minimal example with the adjustments people suggested on this thread.

YuXin

@SGaist that's ok

YuXin

@hskoglund First of all, I sincerely apologize for the delayed reply—I’ve been extremely busy.

Secondly, your proposal is indeed feasible, but I’d like to know what you mean by "race condition"—I’ve never heard of it before.

Is there any documentation that explains this?

jsulm

@YuXin https://en.wikipedia.org/wiki/Race_condition

YuXin

@hskoglund I looked into it: when changing the progress bar value, it internally calls
repaint, which should trigger an immediate redraw.

On the other hand, the label uses
update, but the call to
update shouldn’t be executed until the
repaint is completed. Moreover, by the time this timer event starts, the previous drawing of the label should already have been completed.

Why would there be a race condition in this scenario?

Christian Ehrlicher

There is no race condition but you use QGraphicsDropShadowEffect for a child widget with a radius of 10 so this widget is responsible for drawing everything of it's size + 10 pixel which overlaps with your progressbar.
I don't understand why you use QGraphicsDropShadowEffect with this large radius at all. What do you want to achieve for a plain QWidget not in a QGraphicsScene?

YuXin

@Christian-Ehrlicher I also think there is no race condition here, but can you tell me why their overlapping drawing areas would cause this? I'm really curious about the reason, even though I already know the solution.

Christian Ehrlicher

As I said - the effect draws outside it's client area.