Почему код GUI является так в вычислительном отношении дорогим?

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

Среди библиотек, пишущий библиотеку инструментария GUI заметно трудная проблема. Это вызвано тем, что программы, которые пользуются библиотеками GUI, передвигаются на очень большое разнообразие доменов с совсем другими потребностями. Г-н, Почему и Martin DeMollo обсудил требования, помещенные библиотек GUI только что.

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

Так, GUI являются медленными из-за неэффективности, представленной механизмами абстракции, используемыми для создания высоко допускающих повторное использование компонентов, которые добавили к краткости времени, доступного для оптимизации кода, после того как так много времени было проведено, просто разбираясь в поведении.

Я действительно до некоторой степени завишу от языка. Вы, возможно, заметили, что Java и приложения RealBasic немного медленнее, чем их на базе С (C++, C#, Objective C) дубликаты.

Однако приложения GUI намного более сложны, чем приложения командной строки. Окно терминала должно только потянуть простое окно, которое не поддерживает кнопки.

Существует также несколько циклов для дополнительных исходных данных и функций.

Я думаю, что можно найти некоторые интересные мысли об этой теме в "Дизайне Оконной системы: Если у меня был он для переделывания снова в 2002" James Gosling (парень Java, также известный его работой над pre-X11 системами управления окнами). Доступный онлайн здесь [PDF].

Статья фокусируется на положительной стороне (как сделать ее быстро), не на отрицательной стороне (что заставляет ее замедлиться), но это - все еще хорошее чтение по теме.

Uhm, это довольно много.

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

Все объяснять, разгружая вычисления к GPU не обязательно решит любые проблемы. GPU точно так же, как ЦП кроме он - менее общая цель, и больше данные нашел что-либо подобное процессору. Это может сделать графические вычисления исключительно хорошо. Безотносительно графического API/ОС и комбинации драйвера, которую Вы имеете, действительно не имеет значения так очень... хорошо хорошо, с Vista как пример, они изменили настольный механизм состава. Этот механизм намного лучше удобряет компостом только то, что изменилось, и так как горлышко бутылки номер один для приложений для GUI перерисовывает, аккуратная стратегия оптимизации. Эта идея виртуализировать Ваши вычислительные потребности и только обновляет самое маленькое изменение каждый раз.

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

Сегодня этот вид графической обработки не обязательно существует. Я сказал бы, что люди воздержались от записи действительно эффективных и виртуализирующих решений для рендеринга, потому что порция преимущества/стоимости довольно низко/высоко (плоха).

Что-то, что делает Windows Presentation Foundation (WPF), который я думаю, далеко превосходит большую часть другого API GUI, то, что он разделяет обновления расположения и представляющие обновления в две отдельных передачи. И в то время как WPF является управляемым кодом, механизм визуализации не. То, что происходит с рендерингом, - то, что управляемый механизм визуализации WPF создает очередь команды (это - то, что DirectX и OpenGL делают), которого затем вручают собственному механизму визуализации. Что немного более изящно, вот то, что WPF затем попытается сохранить любое вычисление, которое не изменило визуальное состояние. Прием, если Вы можете, где Вы избегаете дорогостоящего рендеринга, призывает к вещам, который не должен быть представлен (виртуализировав).

В отличие от WM_PAINT, который говорит окну Win32 перекрашивать себя, приложение WPF проверило бы, какие части того окна требует перекрашивания, и только перекрасьте самое маленькое изменение.

Теперь WPF не является высшим, это - твердое усилие от Microsoft, но это не Святой Грааль еще... код, который работает, конвейер мог все еще быть улучшен, и объем потребляемой памяти любого управляемого приложения является еще больше, чем я хотел бы. Но я надеюсь, что это - вид ответа, который Вы ищете.

WPF может сделать некоторые вещи, асинхронно довольно достойные, который является огромным соглашением, если Вы хотите сделать действительно быстро реагирующий low-latency/low-cpu UI. Асинхронные операции больше, чем разгружают работу над другим потоком.

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