什么是WPF WebBrowser控件的一个很好的替代品？

Question

I have an MDI WPF app that I need to add web content to. At first, great it looks like I have 2 options built into the framework the Frame control and the WebBrowser control. Given that this is an MDI app it doesn't take long to discover that neither of these will work.

The WPF WebBrowser control wraps up the IE WebBrowser ActiveX Control which uses the Win32 graphics pipeline. The " Airspace " issue pretty much sums this up as "Sorry, the layouts will not play nice together".

Yes, I have thought about taking snapshots of the web content rendering these and mapping the mouse and keyboard events back to the browser control, but I can't afford the performance penalty and I really don't have time to write and thoroughly test it.

I have looked for third party controls, but so far I have only found Chris Cavanagh's WPF Chromium Web Browser control. Which wraps up Awesomium 1.5 . Together these are very cool, they play nice with the WPF layouts. But they do not meet my performance requirements. They are VERY HEAVY on memory consumption and not to friendly with CPU usage either. Not to mention still quite buggy. I'll elaborate if you are interested.

So, do any of you know of a stable performant WPF web browser control?

Thanks.

Answer 1

I don't think there are many fully-managed web controls. There's an unusual one at http://www.modeltext.com/html/ (I'm its author).

This a Windows Forms control, not WPF. The Windows Forms – WPF Interoperability FAQ suggests that's not a problem; but I don't know whether the "airspace problem" precludes using a Windows Forms control.

On the plus side:

• Fully managed
• Performant: low CPU at least (I don't know what your memory requirements are)
• Can have more than one instance of it in an application

On the minus side:

• Only a subset of the functionality that would be supported by a mainstream browser (so, it depends what you want it for)
• Beta quality

---

Edit:

Looks like nice work.

Thank you.

For this application I need a fully functional browser (I must support javascript).

In that case, this wouldn't work for you: this control exposes .NET (not javascript) DOM APIs; so, applications can implement and install DOM event handlers, which are written in C# instead of in javascript.

And yes, hosting the control in a WPF app will work fine until you need to layer your objects. All winforms controls will suffer from this problem due to the rendering pipelines. See the link above. Have you considered a native WPF port?

A WPF port might be possible, because it renders onto/via an abstract device-context-like interface, of which I have two complete/distinct implementations so far:

• One uses System.Windows.Forms and System.Drawing
• The other is my automated test framework, which implements the 'humble dialog' pattern for GUI regression testing

Theoretically perhaps I could implement a third, for WPF, using System.Windows.Controls and System.Windows.Media .

Kind of random but you might find this interesting: http://blog.spencen.com/2008/01/19/html-to-flowdocument-converter.aspx

Thank you for that: I do find that interesting. The WPF RichTextBox provides a lot of functionality for editing.