Hi,

If you just want to load the HTML (without getting it back). You can try using Custom Resource handler and seek if it helps:

http://www.essentialobjects.com/doc/webbrowser/advanced/resource_handler.aspx

If that still does not help, you may need to cut your HTML string down into small parts. The reason that EO.WebBrowser is slower is probably due to the multi-process architecture. First, the browser engine runs outside of your application process. This isolates the browser engine from your application and gives us a number of benefits. For example, if a buffer overrun occurred inside the browser engine, it will not mysteriously corrupt managed code in your own application. Additionally, chrome browser engine itself uses multiple child process for different roles. For example, GPU is running in a separate process, plug-in is running a separate process, render is running in a separate process, etc.. Chrome originally supported single process model, but that has been removed many years ago. So if you use a reasonably updated Chrome engine, then it would only run in multi-process mode.

This double process isolation works great for most cases, but unfortunately when you have huge HTML strings, it results in a lot of memory copying. So it will be the best for you to split it into small parts.

Thanks!

Hi,

You usually do not have to handle all resource requests with custom resource handler. When you use a custom resource handler, you would override its Match method to decide which request you want to handle. If you return true there, then you are responsible to feed the Resonse object for that Request object. If you return false, then the browser engine will continue with its default handler. So you are not canceling any resources at all. You are basically just converting a LoadHtml into a LoadUrl. For example, you can call LoadUrl("http://myhugehtml") and then check that Url in your resource handler. You would then feed your huge html to the Response object in your custom resource handler.

We do not have a clear value on how much it achieve fast loading time since it depends on the computer. However you would want to keep in mind that a web browser is designed to display "normal" size pages. So for example, a web page that takes less than 10 pages to print out would probably be consider normal, but a page that takes 100 pages when printed would be on the "not normal" side. While displaying such page is possible, you should be aware that performance optimizations for pages of this size would never be a priority of the browser engine team. So from a practical point of view, you definitely would not want to push the boundary too far.

Thanks