Forcing screen updates
-
Thinking about it, I can "simulate" the worst of what is happening with just:
QTimer timer; connect(&timer, &QTimer::timeout, this, []() { /* do nothing, so it's quick! */ }); timer.start(0);That's a 0-interval keep happening and doing nothing. So lots per second! At this point, if I try to close the window I claim I have to wait ages till it (Qt event loop) notices it. That can happen, say, a minute after I clicked the close button.
Then just add into the timeout slot a
QElapsedTimerto update a label once per second. I claim I rarely get to see these updates ever shown on screen. Might happen a lot later, like the response to the window close button input does.So I have something to try in due course, unless anyone else is intrigued enough to see how Qt behaves under this load :)
-
Well, mystery behaviour solved. The culprit is calling
QWidget::setWindowTitle()too frequently! Here is an absolutely minimal standalone repro:#include <QApplication> #include <QTimer> #include <QWidget> int main(int argc, char *argv[]) { QApplication a(argc, argv); QWidget w; w.setGeometry(100, 100, 300, 100); w.show(); QTimer timer; timer.setInterval(0); int count = 0; // change next line down to `count % 100 == 0` and for me everything freezes completely! :( QObject::connect(&timer, &QTimer::timeout, [&]() { count++; if (count % 1000 == 0) w.setWindowTitle(QString("%1").arg(count)); } ); QTimer::singleShot(1000, [&timer]() { timer.start(); } ); // ensure widget actually gets time to show initially, even on fastest timer interval above return a.exec(); }I am on Qt 15.5.3 under Ubuntu 20.04, using GNOME/X windows. This is in a VirtualBox VM under Windows. I periodically update the window title to show the simulation generation number as above.
In the above code, if updating the window title every
if (count % 1000 == 0)all works fine. But if I reduce that toif (count % 100 == 0)my whole system "freezes". Not only do I not see the title updates, not only does it not respond if I click the window's close box, but even the VM's Linux "shutdown" command fails to shut down Linux. I have to use the VM's "powerdown" command to force-terminate the whole OS!So the gist here must be: if sending lots of "title update"s frequently the whole windowing system must get so "busy" servicing the title updates that it becomes totally unresponsive.
If anybody would care to reproduce above code on their platform I should be most interested to hear behaviour on yours?! If your system is faster/slower than mine you might have to adjust the
count % 100, e.g. down tocount % 10or evencount % 1.Obviously I now have a solution: I will change the condition for showing the title over to a
QElapsedTimerso the user only sees the updates, say, 10 times per second. -
Well, mystery behaviour solved. The culprit is calling
QWidget::setWindowTitle()too frequently! Here is an absolutely minimal standalone repro:#include <QApplication> #include <QTimer> #include <QWidget> int main(int argc, char *argv[]) { QApplication a(argc, argv); QWidget w; w.setGeometry(100, 100, 300, 100); w.show(); QTimer timer; timer.setInterval(0); int count = 0; // change next line down to `count % 100 == 0` and for me everything freezes completely! :( QObject::connect(&timer, &QTimer::timeout, [&]() { count++; if (count % 1000 == 0) w.setWindowTitle(QString("%1").arg(count)); } ); QTimer::singleShot(1000, [&timer]() { timer.start(); } ); // ensure widget actually gets time to show initially, even on fastest timer interval above return a.exec(); }I am on Qt 15.5.3 under Ubuntu 20.04, using GNOME/X windows. This is in a VirtualBox VM under Windows. I periodically update the window title to show the simulation generation number as above.
In the above code, if updating the window title every
if (count % 1000 == 0)all works fine. But if I reduce that toif (count % 100 == 0)my whole system "freezes". Not only do I not see the title updates, not only does it not respond if I click the window's close box, but even the VM's Linux "shutdown" command fails to shut down Linux. I have to use the VM's "powerdown" command to force-terminate the whole OS!So the gist here must be: if sending lots of "title update"s frequently the whole windowing system must get so "busy" servicing the title updates that it becomes totally unresponsive.
If anybody would care to reproduce above code on their platform I should be most interested to hear behaviour on yours?! If your system is faster/slower than mine you might have to adjust the
count % 100, e.g. down tocount % 10or evencount % 1.Obviously I now have a solution: I will change the condition for showing the title over to a
QElapsedTimerso the user only sees the updates, say, 10 times per second.I have tested your sample on macOS 12.6.5 with 1000, 100, 10, 1 and Qt 5.15.2 and 6.4.3.
It worked without any issue in all cases. Meaning I could resize the window and see the window title update.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
I have tested your sample on macOS 12.6.5 with 1000, 100, 10, 1 and Qt 5.15.2 and 6.4.3.
It worked without any issue in all cases. Meaning I could resize the window and see the window title update.
@SGaist
This implies one of two things:-
My machine is very, very much faster than yours, so I can pound the event queue more. This seems highly unlikely :)
-
Any combination of: you have a Mac and (so I hear) they just work (but are for rich people/artists), I have a rubbish machine, X11/GNOME/Ubuntu can't cope, VirtualBox is a problem, I am jinxed ;-)
Thanks for testing. I am OK now that I have identified the problem here, and changed over to a
QElapsedTimerto throttle the title updates. -
-
J JonB has marked this topic as solved on
-
@SGaist
This implies one of two things:-
My machine is very, very much faster than yours, so I can pound the event queue more. This seems highly unlikely :)
-
Any combination of: you have a Mac and (so I hear) they just work (but are for rich people/artists), I have a rubbish machine, X11/GNOME/Ubuntu can't cope, VirtualBox is a problem, I am jinxed ;-)
Thanks for testing. I am OK now that I have identified the problem here, and changed over to a
QElapsedTimerto throttle the title updates.- I am rather inclined on the "OS API is different"
- You forgot the corporate machines, refurbished, etc variants ;-)
Additional test done with KDE Neon using Wayland on an x86_64 machine with an old NVIDIA card: 1000 and 100 works fine, at 10 I get "The Wayland connection experienced a fatal error: Resource temporarily unavailable" and the app crashes after, literally, a couple of seconds and seems to trigger some restart of other elements but without crashing the whole session (i.e. I can see the desktop background go black and back to the wallpaper and the menu bar disappear and reappear).
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
-
- I am rather inclined on the "OS API is different"
- You forgot the corporate machines, refurbished, etc variants ;-)
Additional test done with KDE Neon using Wayland on an x86_64 machine with an old NVIDIA card: 1000 and 100 works fine, at 10 I get "The Wayland connection experienced a fatal error: Resource temporarily unavailable" and the app crashes after, literally, a couple of seconds and seems to trigger some restart of other elements but without crashing the whole session (i.e. I can see the desktop background go black and back to the wallpaper and the menu bar disappear and reappear).
@SGaist
Thank you for your further test. Now I trust you do not think I am going mad/reporting nonsense ;-) As I said, on my platform it is so bad that you cannot interact with anything on the desktop.Worse, the desktop does not respond to the Ctrl+Alt+F3 key combination to switch to a console login where I could have killed the process and then returned to the desktop. And the VM's standard Linux "shutdown" order is ignored. Which leaves me with only the VM's "powerdown", which immediately terminates the OS rudely. Do you have any idea how many times I have had to do this and reboot the machine while developing...? :(
-
@SGaist
Thank you for your further test. Now I trust you do not think I am going mad/reporting nonsense ;-) As I said, on my platform it is so bad that you cannot interact with anything on the desktop.Worse, the desktop does not respond to the Ctrl+Alt+F3 key combination to switch to a console login where I could have killed the process and then returned to the desktop. And the VM's standard Linux "shutdown" order is ignored. Which leaves me with only the VM's "powerdown", which immediately terminates the OS rudely. Do you have any idea how many times I have had to do this and reboot the machine while developing...? :(
Never thought madness was involved. The first thing that came to mind when you wrote that it was due to setWindowTitle was that it was likely the kind of API that was not necessarily meant to be updated that frequently. And beside that, it's one of the parts that is handled outside of Qt so there might some more things coming into play.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Never thought madness was involved. The first thing that came to mind when you wrote that it was due to setWindowTitle was that it was likely the kind of API that was not necessarily meant to be updated that frequently. And beside that, it's one of the parts that is handled outside of Qt so there might some more things coming into play.
@SGaist said in Forcing screen updates:
not necessarily meant to be updated that frequently. And beside that, it's one of the parts that is handled outside of Qt so there might some more things coming into play.
Absolutely! Just something which didn't really occur to me, didn't realise I was hitting it quite so often or more to the point that it would cause complete non-operation of the desktop!
-
@SGaist said in Forcing screen updates:
not necessarily meant to be updated that frequently. And beside that, it's one of the parts that is handled outside of Qt so there might some more things coming into play.
Absolutely! Just something which didn't really occur to me, didn't realise I was hitting it quite so often or more to the point that it would cause complete non-operation of the desktop!
@JonB Just to be sure: Have you optimized your Vbox VM? I mean, installed guest drivers, set hyper-v paravirtualization in settings, 3d accel on,etc? In another thread here I complained about the lack of graphics performance of Vbox and why I switched to VMware - in the end switching to native linux as performance gap was still too much.
If you are on Win 11 you also might want to try Windows Subsystem for Linux. So far everybody seems to be surprised by the performance of graphics apps.
Just for fun‘s sake you could try to use xpra to forward all X11 calls to your native windows machine. This might improve performance as well :D
We had a similar problem in the early 2000s on Solaris SPARC systems using Motif/X11. Flooding the system just froze the machine as the graphics card was not fast enough to process all the X11 protocol calls (the majority are synchronous). -
@JonB Just to be sure: Have you optimized your Vbox VM? I mean, installed guest drivers, set hyper-v paravirtualization in settings, 3d accel on,etc? In another thread here I complained about the lack of graphics performance of Vbox and why I switched to VMware - in the end switching to native linux as performance gap was still too much.
If you are on Win 11 you also might want to try Windows Subsystem for Linux. So far everybody seems to be surprised by the performance of graphics apps.
Just for fun‘s sake you could try to use xpra to forward all X11 calls to your native windows machine. This might improve performance as well :D
We had a similar problem in the early 2000s on Solaris SPARC systems using Motif/X11. Flooding the system just froze the machine as the graphics card was not fast enough to process all the X11 protocol calls (the majority are synchronous).@DerReisende
Goodness knows :) I'm wedded to VirtualBox coz I just about know how to use it. I did "ESXi", that's VMware isn't it, and found it a nightmare to manage! I will have a look tomorrow at graphics settings, normally I don't think about them, didn't occur to me as I'm only writing to a window title, but who knows.About the only UI that was 100.00% reliable was a VT220, ever since windowing systems there have always been problems....
