Using CEF from non-main application thread?

[magreenblatt]

You can use CefSettings.multi_threaded_message_loop on Linux.

[VadZ]

You can use CefSettings.multi_threaded_message_loop on Linux.

Hmm, interesting, thank you. I had seen this, but I assumed I shouldn't be using this because it was incompatible with using "external_message_pump = true" (enabling both of them results in an immediate crash as soon as CefDoMessageLoopWork() is called), but it does seem to work fine on its own. There is something wrong with scaling in high DPI, of all things (no idea how does the choice of an event loop can affect this, but it does!), but otherwise it seems to work fine in my very limited testing so far.

Are there any drawbacks to using "multi_threaded_message_loop = true" or, alternatively, to not using "external_message_pump = true" other than it not working under Mac (this is a big drawback as I'd need to maintain 2 versions of this code, but I could live with this if it allows to have better UI/UX under the other platforms)?

[magreenblatt]

Are there any drawbacks to using "multi_threaded_message_loop = true"

Some bugs, see https://github.com/chromiumembedded/cef ... el%3Alinux

[VadZ]

Just to (hopefully) wrap up this thread, I think I've solved my problem by doing something similar to what Chrome itself does with its `ObserverSource`. I.e. I now add a dummy `GSource` to the main (not thread-specific) context and wake up my idle callback from its "check" function. This ensures that as soon as poll in the main event loop notices there is anything to do, my idle callback is called and I can just dispatch the events on the thread-specific context from there.

The thing I hadn't initially understood was that even if poll in the main event loop wakes up, it doesn't actually do anything with the X events meant for Chrome, as they must be processed by the sources attached to another context. And without my dummy source the main loop would wake up, realize it has nothing to do and resume polling again until it finally got something that it could handle.

Also, I believe that with this approach I might not need to override OnScheduleMessagePumpWork() at all with this approach, but it doesn't cost me anything to keep it, and it is being called as often as in the main thread again now.