QProgressBar has rendering errors or does not render at all
-
@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.
-
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 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.
@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 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.
-
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++)); } ...@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?
-
@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?
-
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++)); } ...@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
updateshouldn’t be executed until the
repaintis 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?
-
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? -
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?@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.
-
As I said - the effect draws outside it's client area.
