Что является хорошей альтернативой элементу управления WPF WebBrowser?

Question

У меня есть приложение MDI WPF, к которому нужно добавить веб-контент. Поначалу здорово, похоже, у меня есть 2 опции, встроенные в фреймворк: элемент управления Frame и элемент управления WebBrowser . Учитывая, что это приложение MDI , не займет много времени, чтобы обнаружить, что ни один из них не будет работать.

Элемент управления WPF WebBrowser объединяет элемент управления IEX WebBrowser , использующий графический конвейер Win32. Проблема " Airspace " в значительной степени обобщает это как "Извините, макеты не будут хорошо играть вместе".

Да, я думал о том, чтобы сделать снимки веб-контента, отображающие их, и сопоставить события мыши и клавиатуры с управлением браузером, но я не могу позволить себе снижение производительности, и у меня действительно нет времени для написания и тщательно проверить это.

Я искал сторонние элементы управления, но до сих пор нашел только Крис Кавана WPF Chromium Web Browser . Который окутывает Awesomium 1.5 . Вместе они очень крутые, они хорошо играют с макетами WPF. Но они не соответствуют моим требованиям к производительности. Они ОЧЕНЬ ТЯЖЕЛЫЕ по потреблению памяти и не слишком дружат с загрузкой процессора. Не говоря уже о довольно глючной. Я уточню, если вам интересно.

Итак, кто-нибудь из вас знает о стабильной производительности WPF элемент управления веб-браузера?

Спасибо.

Answer 1

Я не думаю, что есть много полностью управляемых веб-элементов управления. Есть необычный http://www.modeltext.com/html/ (я его автор).

Это элемент управления Windows Forms, а не WPF. В Windows Forms - FAQ по совместимости WPF предполагается, что это не проблема; но я не знаю, исключает ли «проблема воздушного пространства» использование элемента управления Windows Forms.

С положительной стороны:

• Полностью управляемый
• Производительность: по крайней мере, низкая загрузка ЦП (я не знаю, каковы ваши требования к памяти)
• Может иметь более одного экземпляра в приложении

На минусовой стороне:

• Только подмножество функций, которые будут поддерживаться основным браузером (поэтому, это зависит от того, для чего вы этого хотите)
• Бета-качество

---

Edit:

Похоже, хорошая работа.

Спасибо.

Для этого приложения мне нужен полнофункциональный браузер (я должен поддерживать javascript).

В этом случае это не сработает для вас: этот элемент управления предоставляет API-интерфейсы DOM .NET (не javascript); поэтому приложения могут реализовывать и устанавливать обработчики событий DOM, которые написаны на C # вместо javascript.

И да, размещение элемента управления в приложении WPF будет работать нормально до тех пор, пока вам не понадобится наложить свои объекты. Все элементы управления winforms пострадают от этой проблемы из-за конвейеров рендеринга. Смотрите ссылку выше. Вы рассматривали собственный порт WPF?

Порт WPF может быть возможен, потому что он рендерится на / через абстрактный интерфейс, подобный контексту устройства, из которого у меня есть две полные / отличные реализации:

• Один использует System.Windows.Forms и System.Drawing
• Другой - мой автоматизированный каркас тестирования, который реализует шаблон «скромного диалога» для регрессионного тестирования графического интерфейса пользователя

Теоретически, возможно, я мог бы реализовать третий, для WPF, используя System.Windows.Controls и System.Windows.Media.

Случайно, но вы можете найти это интересным: http://blog.spencen.com/2008/01/19/html-to-flowdocument-converter.aspx

Спасибо за это: я нахожу это интересным. WPF RichTextBox предоставляет множество функций для редактирования.