Unsolved How to force X11 to repaint?
-
QCoreApplication::processEvents() on Ubuntu is not ensuring that the window contents are drawn - I'm guessing because X11 is async. Is there way to make sure the window is refreshed besides dodgy timers?
I tried QCoreApplication::flush() with no effect as well. Right now, I have to use a dodgy timer 50ms workaround before continuing and that won't fly with X11's networking capabilities.
-
@Vadi2 Why do you need to repaint? Are you blocking the event loop?
-
Yes, I'm doing a lot of work on the main thread.
-
Hi,
It sounds like you should consider delegating some stuff to a secondary thread.
-
The work that I am doing actually involves creation of the GUI - it just takes a really long while to do everything. There is a lot of QWidgets and QLabels involved.
So there is no way to wait until X11 syncs to continue?
-
What kind of GUI are you creating ?
How many widgets are there ?
-
I'm not sure how to count them. Here's how it looks like when I have a 0ms timer before I start doing the bulk of creation though:
https://transfer.sh/14dDdv/Kazam_screencast_00013.mp4
And here's how it looks like when I put in an artificial 50ms delay:
https://transfer.sh/mrSDy/Kazam_screencast_00014.mp4
The theoretical problem is that since X11 is async and allows for networking, and even though it is on its way out the door, there potentially could be a networked case where the 50ms delay is not enough and the user would see the behaviour in the first video. For this I'd like to force Qt to repaint before doing the bulk of creation.
-
Do you really need to create them all on startup ?
-
Yeah.
I'm thinking of adding some of a loading widget to cover the entire screen while Qt does stuff in the background, though I realise now it won't work as it's all on one thread.
-
But why all of them ? Shouldn't you use lazy loading so that screens that a player doesn't use don't wastes memory and cpu cycles ?
-
In this case the player has marked all those screens to be loaded - by default, none are.
Still having troubles figuring out a good solution for this :|
-
@Vadi2 Typically this is what applications use a splash screen for. It's so you can load your gui while showing a progress bar and a splash screen. This is acceptable to users since they can see something is happening and it is better for you since your GUI will be fast once it's all built and loaded.
Even GIMP does it in linux. Although most apps don't need to any more since CPUs have gotten so fast.
-
You have an idea with the splash screen. I do have one before this, but it is possible there will be user input, it's not shown after - I think I could make something work here.
-
@Vadi2 Yea so you're basically just hiding the interface as you build it, while showing the splash screen (sometimes with a progress bar), and then when it's ready you hide the splash and show the interface. That show should be fast since it doesn't create anything.