There is definitely exists situations when applications create WebBrowser on-demand basis, and even exists cases when it is possible that it never been created.
In other words if we create some Window/Form - actual any underlying handles/controls created only when them becomes exactly visible including CefWebBrowser.
In same time there is still exists sense create CefWebBrowser on main application UI thread for some reasons:
1. Avoid additional thread synchronization / message passing.
2. Avoid input stealing/focus problems (sometimes code implies on foreground input thread - sometimes doesn't, that means that embedding into other thread is becomes very tricky, while surrounding UI controls did not ready for this situations).
3. From my understanding, in GTK+ it is not an option create second message loop on other thread, at least i'm assume that on Linux and OSX always have one UI message loop. Plese correct me here, if i'm wrong.
Personally (on Windows) - i'm use this lazy technique in this manner.
1. I'm start standard message loop & do any native UI stuff.
2. Once i'm needed in CefWebBrowser - i'm initialize CEF if needed on UI thread.
3. Once initialization is done, i'm replace current message loop with CefRunMessageLoop.
(*) From my understanding, CefDoMessageLoopWork acts as short-living 'normal' platform message loop? This means, that if we implement something like message filtering - it is possible that some messages will not be filtered inside. Please, correct me here if i'm wrong.
Problem in above - that CefInitialize block UI thread - and it is executed relatively slowly. It depends from hardware, cache, etc. On real and not bad hardware it is happens very fast, but on same with cold start - this call can take up to 600ms, and i'm assume that there is HDD-related. On single-processor VM - it is can takes much longer (few seconds). Worst case that i'm seen has been ~20 seconds. And i'm still agree, that disk-performance is bottleneck. Problem that it is degrades too much fast, and we can't predict environment where we run. It is why i'm want to show some load animation early, i.e. just before CefInitialize call, but there is no have sense, 'cause UI thread blocked anyway.
I'm seen interesting issue: #1639 which is weakly related to this post.
So if we want solve this problem now - we should use CEF on different thread (with drawbacks). Or initialize CEF on startup (what increases application startup time). Or even leave as-is.
And finally hypothetical question: what if we do all initialization work on different thread, with calling back to target thread whenever it is really need?
I'm assume that really thread-bound initialization is can be related to some system API calls, and of course to some pieces of chromium-owned code (which kind of code it is?).
Unfortunately, i'm did not believe that it is really possible without rewriting lot amount of code in content/ folder, so just discuss about. May be i'm miss some options.
(*) I'm known that it is pretty common situation, that under heavy disk load, any UI becomes non-resposive. But in same time, windows 8+ shows that code which did not block UI thread - responsive, and even animations looks not bad. So, actual 'freezing' comes from code, and then from hardware.
Thanks.