Почему большинство пользовательских интерфейсов однопоточных?

Например, Java Swing и Android UI используют одну поточную модель, в которой для обновления всего пользовательского интерфейса отвечает один stream пользовательского интерфейса. Что заставило дизайнеров фреймворка выбрать одну модель streamа над другой?

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

Что заставило дизайнеров фреймворка выбрать одну модель streamа над другой?

Из уст лошади :

Первоначально AWT была показана как обычная многопоточная библиотека Java. Но поскольку команда Java посмотрела опыт работы с AWT и с тупиками и расами, с которыми столкнулись люди, мы начали понимать, что мы обещаем, что не можем удержать.

Этот анализ завершился одним из обзоров дизайна для Swing в 1997 году, когда мы рассмотрели состояние игры в AWT и общий отраслевой опыт, и мы приняли рекомендацию команды Swing о том, что Swing должен поддерживать только очень ограниченную multithreading.

(Прочитайте всю статью, она подробно объясняет это решение и заявляет, что точно такие же проблемы и возможный переход к однопоточной модели произошли ранее в Xerox PARC – месте, где почти все, что мы рассматриваем, стало кровоточить, современное в CS, было изобретен 30 лет назад)

Не будет ли многопоточная модель пользовательского интерфейса потенциально давать вам больше производительности, хотя бы за счет большей сложности?

Абсолютно нет, потому что рисование GUI и обработка пользовательских действий (которые все, что нужно для streamа пользовательского интерфейса) не будут узким местом в любом нормальном 2D приложении.

Не будет ли многопоточная модель пользовательского интерфейса потенциально давать вам больше производительности, хотя бы за счет большей сложности?

Не в большинстве случаев, и что добавленная сложность принесет больше вреда, чем пользы в большинстве случаев. Вы также должны понимать, что инфраструктура пользовательского интерфейса должна иметь дело с базовой моделью ОС. Конечно, он мог бы обойти модель и отвлечь ее от программиста, но в этом случае это просто не стоит.

Количество ошибок, вызванных несколькими streamами, обновляющими ad hoc ad hoc, намного перевешивало бы то, что было бы по большей части бессмысленным выигрышем в производительности (если бы были даже выигрыши, streamовая передача с соответствующими накладными расходами из-за блокировки и синхронизации, вы можете на самом деле просто сделать производительность хуже в то время).

В этом случае лучше использовать несколько streamов явно и только тогда, когда это необходимо. Большую часть времени в пользовательском интерфейсе вы хотите, чтобы все было на одном streamе, и вы ничего не выигрываете, если использовать несколько streamов. Интерфейсы пользовательского интерфейса почти никогда не являются узким местом.

Нет, наверное, нет. По крайней мере, когда вы пытаетесь запустить streamи на CPU. На GPU уже существует много параллельной обработки в различных формах. Не так много для простой работы графического интерфейса, но для фантазии 3D (затенение, reflection и т. Д.),

Я думаю, это все о предотвращении тупиковой ситуации.

Компоненты Swing не считаются streamобезопасными, и они не обязательно должны быть из-за этого события Dispatcher Thread. Если пользовательский интерфейс был многопоточным, все приложение должно было бы полагаться на каждый компонент, ведущий себя в streamобезопасной манере, а если таковой вообще не был, то в неясных ситуациях могут возникать взаимоблокировки.

Таким образом, это безопаснее.

Не только это, но тот же дизайн был выбран Windows Forms (& .Net), GTK, Motif и другими. Интересно, будет ли Java принуждаться к этому решению базовыми API-интерфейсами ОС, с которыми они взаимодействуют. Разумеется, SWT в этой ситуации принуждается Windows Forms.

Для получения дополнительной информации «EDT» – хорошее место для запуска http://en.wikipedia.org/wiki/Event_dispatching_thread

Для .NET эквивалент SwingWorker известен как BackgroundWorker.

Это связано с природой приложения пользовательского интерфейса.

Вы должны прочитать ввод (мышь или клавиатура), отправить события, позволить им обрабатывать и снова рисовать экран.

Попробуйте сделать это на многопоточном процессе.

  • Как определить несколько действий JButton из другого classа
  • Эффект JavaFX на фоне
  • Как стиль PopupMenu?
  • Дизайн пользовательского интерфейса Blackberry - настраиваемый пользовательский интерфейс?
  • Обновление пользовательского интерфейса Android с помощью streamов
  • GUI работает со скоростью 30 кадров в секунду?
  • Создать редактор гитарных аккордов в WPF (из RichTextBox?)
  • Как выравнивать представления в нижней части экрана?
  • Как лучше всего настроить Swing GUI?
  • JTable Right Align Header
  • Пользовательская строка заголовка без дополнения (Android)
  • Interesting Posts

    Принудительное клонирование изображения жесткого диска на меньшем жестком диске

    Получение адреса метки в регистр на ARM?

    Переход к следующему элементу управления нажатием клавиши Enter в WPF

    Итерация над значениями в Flags Enum?

    Создание страницы Facebook программно через Open Graph API

    Уведомление о восстановлении задачи, а не конкретной деятельности?

    Подключение к удаленному URL-адресу, для которого требуется аутентификация с использованием Java

    На какой уровень TCP / IP входят MAC-адреса и IP-адреса?

    Эффективно находить точки внутри сектора круга

    CSS3 Поворот анимации

    Почему статический член данных должен быть определен вне classа?

    Что более эффективно? Статические данные, передача данных, общие настройки, firebase database …?

    Планирование R Script

    Поиск всех возможных комбинаций чисел для достижения заданной суммы

    Потребляемая мощность: SSD против HDD

    Давайте будем гением компьютера.