Lightweight and actually asynchronous alternative to WebBrowser control.

[Herman]

As the title says, I am looking for a lightweight (25MB of libraries isn't fun), and actually async way to display webpages in one of my applications.

Everywhere I read, people say that the WebBrowser control is asynchronous, but if it is then I do not know what that word means. Maybe the rendering is done asynchronously, but loading the data from the website blocks the UI thread. I have tried a couple of alternatives, including Awesomium (based off the Chromium Embedded Framework), but they are all pretty heavy, and while they ARE async, the time I save is lost form the extended initial loading times.

Is there something I am missing with the basic WebBrowser control? Is there a way to make the control work in its own thread, without blocking the UI thread?

 

[Dunfiddlin]

It says its ASync because it is ASync. Observe ...

    Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
        WebBrowser1.Navigate("http://www.somenotoriouslyslowloadingsite.com")
        For i = 1 To 200000
            Button1.Text = i.ToString
            Application.DoEvents()
        Next
    End Sub

There might be the odd catch of breath but there is no blocking.

 

[Herman]

There IS blocking. If the site is somehow longer than usual to respond, or if the DNS server takes too long to respond, the UI is completely blocked until it does respond, which in this particular case means 1-2 seconds everytime a user clicks something in the screen that updates the webpage.

Like I said, I do not have the problem with the Chromium framework, but it's HUGE. I was hoping someone knew something a little more lightweight.

 

[wallyg]

There IS blocking. If the site is somehow longer than usual to respond, or if the DNS server takes too long to respond, the UI is completely blocked until it does respond, which in this particular case means 1-2 seconds everytime a user clicks something in the screen that updates the webpage.

Like I said, I do not have the problem with the Chromium framework, but it's HUGE. I was hoping someone knew something a little more lightweight.

Hi, I haven't yet replied to any of these forums, but this one is causing me major grief as well!
I have about 40 computers with different ISP's. They all have different response times and they all cause me problems.
The program I have running also has five webbrowsers and they update the weather every 15 mins. They all block the thread and I would lover to fix it.
Any help would be great.

Thanks Rob.

 

[jmcilhinney]

I haven't actually used the WebBrowser control much myself so I don't know all the ins and outs but, from what you're saying, it sounds like the Navigate method blocks until it receives an acknowledgement from the server and then performs the download asynchronously. That especially makes sense if it's the Navigate method itself that throws an exception if the URL is invalid. I'm not sure whether that is the case or not as I haven't tested, but it sounds reasonable.

I guess a possible alternative may be to use a WebClient or maybe an HttpWebRequest to download the document asynchronously and then assign the result to the DocumentText of your WebBrowser control. I'm not 100% sure whether the WebBrowser will then load all dependencies, e.g. script files, images and subdocuments, but I'm guessing that it will. Those would all be retrieved by the WebBrowser itself though, so you may still have a similar situation.

 

[Herman]

Yeah in the end I went with the CEF, and resolved the initial loading time by loading an instance of the control with a template of the pages I use (they are all the same) to cache the images and scripts and flash on application startup, users will just have to resort to download an additional 25MB. It's just a pity that the MS control doesn't handle that better, but I guess the problem at the core lies in Internet Explorer itself.