Google Chrome имеет несколько процессов, а как насчет потоков пользовательского интерфейса?

Question

Я всегда читал и работал с одним потоком пользовательского интерфейса, так как наличие более одного приведет к нарушению прокачки сообщений и т. Д. И т. Д.

Я отвечаю на свой вопрос здесь, но хочу проверить мое понимание в браузере Chrome, который, как известно, имеет несколько процессов (по одному на вкладку) - ускоряет ли он также некоторую часть рендеринга за счет использования нескольких потоков пользовательского интерфейса?

Я предполагаю, что это НЕ, но если это произойдет, было бы очень интересно узнать или посмотреть какой-нибудь пример кода на c #, чтобы продемонстрировать то же самое (необязательно быть демо веб-браузера).

Любые указатели в направлении нескольких потоков пользовательского интерфейса помогут! спасибо.

Answer 1

Я не могу точно сказать, как Chrome обрабатывает потоки рендеринга, но я бы предположил, что каждая вкладка имеет свой собственный поток рендеринга. Я не вижу смысла проходить через все усилия процесса изоляции вкладок, только чтобы связать их все вместе в общем потоке рендеринга. У всех них будет возможность мешать друг другу.

Я реализовал браузер в стиле chrome с использованием WPF - оболочка приложения представляла собой отдельный процесс, затем каждая вкладка представляла собой надстройку MAF, выполняющуюся в отдельном процессе. Рендеринг был все в дочерних процессах - там не было ничего общего. Каждый AddIn возвращал INativeHandleContract (элемент управления WPF), который был передан через границу процесса.

Результатом этого стало то, что исключение в ЛЮБОМ месте в дочерней вкладке будет только убирать вкладку и может быть обнаружено родительским процессом, что даст ему возможность предоставить некоторую обратную связь / перезагрузить вкладку и т. Д.

Этот документ отсутствовал, когда я его достиг, но после быстрого просмотра я думаю, что в нем есть несколько указателей: http://msdn.microsoft.com/en-us/library/bb909794.aspx

Кент Бугаарт также протянул руку помощи http://kentb.blogspot.com/2008/06/maf-gymnastics-service-provider.html

Вам также может понадобиться этот QFE от Microsoft, чтобы исправить ошибку в сериализации, с которой вы можете столкнуться при передаче элемента управления WPF через границу процесса: http://archive.msdn.microsoft.com/KB982638 Что касается ошибки MS Connect: https://connect.microsoft.com/VisualStudio/feedback/details/467381/wpf-controls-cannot-be-passed-across-process-boundaries

Answer 2

Не путайте потоки и процессы. Каждый процесс будет иметь свой собственный поток пользовательского интерфейса, но, вероятно, также свой собственный насос сообщений.