Изменение объектов GUI через SynchronizationContext

Дело в том, что графическая часть приложения обычно очень сложна. Представьте, например, сложность одного только layout manager'а: ему нужно обходить много раз тысячи объектов, чтобы расставить их по местам. Или код, который находит адресата сообщения от мыши, учитывая hit testing и возможные пользовательские callback'и.

Если сделать эту часть многопоточной, то сложность реализации возрастает на порядки. Кроме того, весь клиентский код должен быть дисциплинирован и применять нужные блокировки в правильный момент. Пример: изменение button.Caption может привести к изменению автоширины этого самого button'а, что в свою очередь может привести к изменению ширины вышестоящих элементов вплоть до окна. Это означает, что в процессе присвоения либо необходимо блокировать всё окно при помощи mutex'а (иначе в двух потоках могут пробегать одновременно два встречных процесса layout management'а с катастрофическими последствиями), либо откладывать обработку на более позднее время (на следующую итерацию оконного цикла).

Второй вариант концептуально намного сложнее, т. к. при этом установка свойств будет происходить не сразу, а позже, то есть, установив ширину контрола и тут же считав её, вы получите не то значение, которое записали. Это не то поведение, которое обычно ожидают от свойств.

А первый вариант (полная блокировка окна) означает, что все операции всё равно сериализованы, то есть, идут не параллельно, а строго одна за одной. Это не даёт никаких потенциальных выгод по сравнению с однопоточным UI (но лишь добавляет сложность для «клиентов» фреймворка).

Именно поэтому почти все UI-фреймворки однопоточны.

Мне приходилось по работе писать многопоточный UI-фреймворк. Поверьте, это не стоит того.