Benefits and Drawbacks of Multi Threaded Message Loop (Windows Forms)
Andreas Kolbow
I am working on a Windows Forms application that uses Xilium CefGlue and I am wondering what the benefits and / or drawbacks of the setting are.
What I found so far:
https://groups.google.com/forum/#!msg/cefglue/4TU0lW_aNlc/j5y0o8uCmyoJ
"On windows using MultiThreadedMessageLoop = true is more applicable, 'cause WinForms doesn't allow inject into message loop, and Application.Idle - called only when application idle, not on each message loop iteration, as actually required. So using Application.Idle is just workaround, which in most cases works fine, expecially with multi-process arch."
http://magpcss.org/ceforum/viewtopic.php?f=6&t=10978
"If you're referring to the multi-threaded message loop option, it's intended for use when integrating CEF into frameworks that have their own hidden message loop implementation. It's better to use CefRunMessageLoop if possible."
http://stackoverflow.com/questions/23790407/embedding-cef3-with-existing-application
"For windows users there is possible to use multi threaded message loop (CefSettings). It is allow maintain browser windows via own message loop. But there is good practice use single threaded message loop, - you can call CefDoMessageLoopWork periodiacally on idle or some additional events. It is possible even with existing message loop."
https://raw.githubusercontent.com/wiki/prepare/CefBridge/GeneralUsage.md
"TID_UI thread is the main thread in the browser process. This will be the same as the main application thread if CefInitialize() is called with a CefSettings.multi_threaded_message_loop value of false."
http://www.magpcss.org/ceforum/viewtopic.php?f=14&t=10883
"Probably better is using single threaded message loop (can be set via cefsettings), in multi-threaded message loop, 'cause windows owned by different threads (maintained by different message loops) - you will got unexpected results with some winforms controls (it's not CEF/CefGlue problem, it is WinForms problem)."
Does anyone know if there are any other things one should know about using or not using MultiThreadedMessageLoop in a Windows Forms application?
Dmitry Azaraev
Hello.
Single-threaded message loop always better option, because it freed you from some cross-threads calls, but main good reason - is that you browser control will be on same thread as other controls. Technically - both options viable, but actually in multi-threaded mode you can easy hit into limitations in winforms controls - some of them do not handle cross-thread focus correctly (some *Strip classes). In other side - you can't completely integrate winforms and CEF message loop into one. So any ways in this mode can lead to that something can broken. But it relates from you app/controls. Most of standard winforms controls works perfectly on standard message loop, so run CEF message loop, instead of winforms - is best from CEF perspective. But you can use app.Idle as well. Both ways partially broken (from winforms perspective), because some events will be processed only by CEF loop (I.e. winforms message filter can miss some message). I'm note, that it is have sense in some special cases, but not in regular cases.
MultiThreaded mode is great when you need integrate into existing application, and did not have extension points. But, in this case - you app anyway should be ready to host content from other threads.
Also, for CEF you anyway should assist for browser controls from hosting window (by chrome design). That lead that it is almost always possible to use single threaded mode.
--
You received this message because you are subscribed to the Google Groups "CefGlue" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cefglue+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Andreas Kolbow
We don't use many Controls or other Windows Forms Dialogs and I haven't encountered any problems with the few we are using so far but it is good to know what to look for. I guess we'll use the single threaded message loop then, just to be sure and to not encounter bugs because of the multi threaded message loop in the future.