I'm trying to speed up the load time of a WebControl (in wpf) and what i'm finding is that it seems like the largest delay is creating the first render process.

I've had some success by pre-creating an invisible WebView, and I can see that i am succeeding in spawning the first 2 background processes that are shared by all WebView instances.

But, when creating actual WebControl instances, it still takes a second or so to get going, as a new render process is created. Maybe it is a little faster for the second and subsequent controls are created, but it's close.

Is there any way to get that first render process created in the background?
This is what I'm doing to create the other background process:

var thr = new Thread(() =>
{
var window = new System.Windows.Forms.Form();
var wv = new EO.WebBrowser.WebView();
wv.Create(window.Handle);
wv.LoadHtml("<html/>");
});
thr.SetApartmentState(ApartmentState.STA);
thr.Start();

and it feels like this does help some, but not quite as good as it could be.

Thanks

Hmm, that is not the behavior that i am observing at all (regarding the site/render process relationship)

When I create my first webcontrol/webview object, pointed at http://www.google.com there are 3 processes created, one of which is type renderer, one is type gpu-process, and one which has no type, but has a --remote-debugging-port argument.

When I add a second webcontrol/webview object, pointed at the same exact url, a new render process is created.
And exactly one new render process is created for each subsequent webcontrol instance created, regardless of the URL.
Further, your answer would seem to suggest that when navigating to a new site in a given browser instance, a new render process would be created. This is not the case, and seems like it would be really bad if it were.

Back to my attempt to jump-start the process creation...
As is, my STA thread does create the 2 non-render processes that are shared across the app.
And, if i add a message loop, it does indeed create a render process as well.
However, as stated above, even if I use the same URL that i will subsequently use to create an actual webcontrol, a new render process is still created at that point. It does not share the one from my pre-load web view.

Having said all that, it does seem like i have succeeded in reducing the initial start time of that first web page somewhat using this approach.

Still curious regarding some clarification on the shared renderer behavior. In my case, if that were true, it might help alot, since most of the instances in use will all be pointed at the same site.

Thanks

Interesting. If the choice of process model could be exposed as a runtime or configuration option, that would be ideal.
No idea how practical that would be of course.
My guess is that process per site would not be most people's choice, unless perhaps there is some mechanism to age out processes at some point if there are no browsers currently viewing a particular site. Otherwise, the proliferation of render processes could become unwieldy.

In my case, the application hosts a number of "tabs" in an MDI sort of way. Some of these tabs are web browsers, some are WPF pages, and some are excel or spreadhseetgear spreadsheets. Of the ones that are web browsers, most all will be viewing different pages from the same (local intranet) site. So for me, the process-per-site might be good.

The down side to that, i imagine, is that should anything go wrong with any of the pages being viewed in the one render process, it would take down the entire bunch. Which, i think, is the entire point of having the out of process architecture in the first place. So, like i say, i would want that to be a configuration option, since even in the situation i described, we still might opt to do process-per-tab.

Thanks.