On Mon, 01/18 10:54, Gerd Hoffmann wrote: > Hi folks, > > I'm starting to investigate if and how we can move the user interface > code into its own thread instead of running it in the iothread and > therefore avoid blocking the guest in case some UI actions take a little > longer. > > opengl and toolkits tend to be bad at multithreading. So my idea is to > have a single thread dedicated to all the UI + rendering stuff, possibly > let even the virglrenderer run in ui thread context. > > I think we have to make that opt-in per user interface, so we can go > forward step by step. > > The ui thread will need quite some stuff provided by the mainloop. Wait > for all kinds of events (from vnc socket, x11 connection, ...). > Probably timers too. Wait for events from other threads (guest screen > updates). > > Suggestions how to tackle that? > Can I reuse the qemu mainloop code outside of the iothread? > Maybe it'll be better to go straight for a glib main loop? > Is it possible to wait for file handle events and posix condition > variables at the same time? > > Other notes / hints / suggestions / ideas?
What are taking long time? Can you give a few examples? Fam