Path of least resistance with CEF Message loop in an Externa

[Gazoo]

Hey CEF forum folks,

I'm trying to find some definitive answers for questions related to the various methods of using CEF inside an external framework. For the record, I have CEF up and running and am experiencing some significant performance issues when my application runs along-side other applications. I'm speculating it's due to my sub-optimal code handling the CEF message loop.

With that in mind, I have these questions:

1. Using CefRunMessageLoop() is out of the question if an external framework runs the OS message loop as this call is blocking and expects to manage both the windows and cef messages, correct?

2. Activating and using multi_threaded_message_loop is preferable to building/using code relying on CefDoMessageLoopWork(), if it's an option, which it is on Windows/Linux, correct?

3. Re. multi_threaded_message_loop, the CEF WIKI - (https://bitbucket.org/chromiumembedded/cef/wiki/GeneralUsage#markdown-header-message-loop-integration) denotes "You will need to provide your own mechanism for communicating with the main application thread" and to look at an example in cefclient_win.cpp. Looking at cefclient_win.cpp I noticed the MainMessageLoopMultithreadedWin object appears to be related to using multi_threaded_message_loop.

The MainMessageLoopMultithreadedWin object looks to be blocking, so I'm thinking it's possible to instantiate it in a separate thread, as its constructor checks which thread it happens to be running in. What eludes me is the additional work required to 'communicate with the main application thread' relating to the MainMessageLoopMultithreadedWin object. Is there any examples of this object being instantiated in its own thread?

Or perhaps I'm misunderstanding something, which is also quite possible.

Thanks in advance,

Gazoo

[magreenblatt]

Use of multi_threaded_message_loop is preferred on Windows/Linux. MainMessageLoopMultithreadedWin::Run() implements a "standard" Windows message loop. If your application/framework already provides a main thread message loop then you likely also already have a mechanism for posting tasks to that main thread.

[Gazoo]

Appreciate the answer magreenblatt.

LibCinder - the framework I use - does handle the Windows message loop, which I assume is what you're referring to?

For other devs reading along, if you're switching on multi_threaded_message_loop, you'll need to make sure that CreateBrowser/CreateBrowserSync is called on the CEF main thread, which is now no longer the main application thread (due to turning on multi_threaded_message_loop). See OsrWindowWin::CreateBrowser() - ..\tests\cefclient\browser\osr_window_win.cc for sample code.

A follow-up question: LibCinder - the framework I'm building in - initiates an OpenGL context on the main application thread which I used to render CEF's OSR output. Turning on multi_threaded_message_loop now has the eventual OnPaint call execute on CEF's thread, and not the main application thread. Given that keeping the OpenGL context on the main application thread is wisest (according to all sources I could find), is there any advice or sample code available for sharing the OSR output across to the main application thread?

As far as I can tell in cefclient, the OpenGL context is instantiated on whatever thread CEF runs on, which is isn't ideal in my case, as LibCinder opens its OpenGL context on the main application thread.

[Gazoo]

I've opted to go with a simple consumer/producer double-buffer which looks to function as intended.

In case it helps anyone else, this is a decent starting point for the code: https://stackoverflow.com/a/23713793/2272951