Cat2HomeCoderА у вас требования к графической карте выполнены? Для некоторых, даже довольно простых, приложений WPF, чтобы исполняться быстро, нужно видеопамяти от 512 МБ.

Вообще, там примерно так. 120 (считай, 128) МБ - это абсолютный минимум для пустого окна. Но, поскольку сама ОС тоже расходует видеопамять и вообще, то уже сразу минимумом становится 256 МБ. Ну и, если у вас достаточно сложный UI, то дальше - больше. Так что даже для средних программок, не перегруженных UI, думаю, от 512 МБ видеопамяти надо.

А то запустят на нетбуке трёлтеней давности с интегрированным видео, а поток ноют, что у них не 60 ФПС и "всё дёргается". Потому что, если памяти не хватает, то сразу всё начинает обрабатываться процессором, а не видеокартой - отсюда и тормоза.
К сожалению для тестирования мне не удалось найти машину у которой видеопамять меньше двух гигабайт
Тогда вступает в действие уже тормознутость и неоптимизированность самого WPF. А точнее, его подсистемы отрисовки.

Про память - это из официальных требований и собственных наблюдений и измерений.

Сон Веры ПавловныHomeCoderТак что даже для средних программок, не перегруженных UI, думаю, от 512 МБ видеопамяти надо.
Как по-вашему, вот такая программка по части перегруженности UI - средняя, или ниже среднего? На рабочем компьютере (Intel C2D E7500 2.39Гц, 3 Гб оперативки, 256 Мб видео, WinXP SP3) она бегает вполне без торможений. WPF4.0.
Она на WPF написана?

Да, это сложная по UI программа. В смысле, что достаточно сложная, чтобы потребить достаточно много видеопамяти.

То, что она "бегает", не значит, что она работает при 60 ФПС без проседаний. К тому же, в ней нет анимаций, скорее всего. А именно на анимациях все тормоза и проявляются. Попробуйте всю эту сложную компоновку анимировать - должно появиться дёргание - т. е. там и 30 ФПСами не пахнет. Штука в том, что отрисовка статичных окон не проблема и для CPU. Они отрисовываются, грубо говоря, за 1 кадр. Просто этот кадр задерживается, пока графическая подсистема весь UI не отрисует. Когда у вас анимации, то задерживаться приходится на каждый кадр - ведь весь UI приходится перерисовывать.

С этой проблемой можно столкнуться и без презентационных анимаций. Например, я сейчас делаю приложение, в реальном времени обновляющее графики (Dynamic Data Dysplay). Например, на график много раз в секунду (столько, сколько успевает процессор) добавляется 1) одна точка, 2) множество точек. И если в 1) графика успевает перерисовываться сносно и я получаю плавную отрисовку "прирастающего" графика, то в 2), если за раз добавляется сразу по 1000 точек (да даже по 100), то видно дёргание. Графическая подсистема просто выбрасывает не успевшие отрисоваться приращения. Т. е. фактически рендерится каждое, скажем, пятое приращение. Точнее, суммарный результат после пятого приращения. Т. е. как будто не 1000 точек приросло, а 5000. При этом приращение данных графика делается в другом потоке (смотрел на Диспетчере Задач - двухъядерный процессор занят на 100%) - т. е. UI ничего не мешает заниматься только отрисовкой.

Кроме того, есть подозрение (но я точно не знаю), что WPF не получает аппаратного ускорения при отключенном Aero на Висте и 7. А у вас на скриншоте, судя по всему, всключена классическая тема UI - без Aero.

Я предлагаю свой анализ событий вокруг WPF.



Именно неэффективность WPF при графических отрисовках - одна из причин, почему WPF не получает развития. МС пытается закрепиться на рынке мобильных устройств. У мобилок слишком мало мощей, чтобы работать с неэффективным WPF. Поэтому WPF не может стать основой для UI на мобилках. Чисто по возможностям, WPF может всё то же, что и Modern UI - плиточки эти пресловутые, мультитач (требует доработки, но невозможного ничего нет). А вот скорости отрисовки не хватает. Доходит до смешного. В Modern UI возможность показать дополнительную информацию на плитках преподносится как революция. С возможностями компоновки WPF это было "из коробки" ещё в 2008 году.

Я не понимаю, почему МС предпочитает не довести до ума то, что есть (оптимизировать графику WPF), а изобрести новое, переписать. Наверное, правы те слухи, что говорят, что в МС "соревнуются" несколько команд, которые на каждую неудачу у коллег предлагают "всё переписать".

Кстати, кто следит за новостями. Думаете, откуда пошла мода на плоские интерфейсы? Я считаю, что причина та же - производительность. Плитки в Modern UI - фон и текст. Ну, картинка какая-нибудь. Иконки в iOS - до 5 слоёв (была статья, где это разбиралось, да и сами разработчики, кто копался в кишках отрисовок там, тоже вкурсе, наверное), включая всякие тени, блики, размытия и альфа-смешивание (прозрачность). Добавьте сюда маркетинговую завлекающую фичу с анимациями интерфейса. В результате из иконок и анимаций в iOS наворотили такую байду, на которую уходила куча ресурсов железа. Эппл и Гугл поняли, что МС хитро сэкономили, не сильно потеряв в визуальном плане (за счёт "своего стиля" и вообще нельзя сказать, что интерфейс плиток хуже, чем размалёванные иконки с кучей эффектов), и получили преимущество - анимировать простые плитки и интерфейс вообще проще. Т. е. требуются меньше мощь железа, меньше батарея, можно обеспечить бОльшее время работы без потери привлекательности интерфейса ("плитки - говно" - вкусовщина, а не объективность, тем более, что плитки - конфетка ).

Вот только по мере развития мощностей мобильных устройств всё снова пойдёт по кругу - тени, блюры, закруглённые края (сложнее отрисовывать же), блики. Пока снова всё не упрётся, но уже в 8-5 нанометров. Давайте смотреть правде в глаза - мобилки, даже в планшетном варианте, никогда не доберутся до производительности сегодняшнего даже бюджетного десктопа за 300 долларов (без монитора). Их предел виден уже давно. А значит, участь WPF была предрешена тоже уже давно.

Алексей КHomeCoderА именно на анимациях все тормоза и проявляются.Там без анимаций тормозов хватает. Тяжёлая модель данных DependencyProperty даёт о себе знать в, например, DataGrid.
Согласен. Только в анимациях можно и вообще без всяких моделей данных и датагридов тормоза узреть. Достаточно погонять по окну, развёрнутом на весь Full HD экран, простую кнопку или картинку.

Почему в WPF тормозят анимации и почему вообще он тормозит. Моё любительское исследование, кому интересно.

gpuАлексей Кпропущено...
Там без анимаций тормозов хватает. Тяжёлая модель данных DependencyProperty даёт о себе знать в, например, DataGrid.
мой опыт показывает что достаточно часто проблема в комбинации степени кривизны рук и отсутствием опыта.
первые версии стилей и прочих приблуд для впф приводили к 50% потере производительностьи при наличии более 20 записей в гриде.

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

результаты превзошли мои ожидания:таки можно получить впф формочку которая летает на большом количестве данных.

правда оптимизировали все:от запросов к базе до логики отображения данных в UI, включая стилей.

сдается мне ,что в 70% случаев проблема в коде и или дизайне. Оставшиеся 30% ограничения технологии.
но сваливать проблемы на технологию значительно проще
Попробуйте тестировать технологию не на каких-то навороченных гридах, а на простых элементах. Погоняйте кнопочку по пустому окну. Только окно сделайте на весь экран и экран чтобы был с разрешением 1920х1080, как это сейчас заведено. Ну и где 60 ФПС? Где вообще хотя бы 30? Сделайте анимацию с прозрачностью, с поворотами и перемещениями по окну - дёргание обеспечено. Конечно, на мощном CPU это будет не так заметно.

А то у вас за датагридами леса не видно.

Алексей КHomeCoder Почему в WPF тормозят анимации и почему вообще он тормозит. Моё любительское исследование, кому интересно.Делали отрисовку графика с большим количеством элементов через VisualBrush. Всё летает.
А железо у вас какое было? А то, может, на современной игровой конфигурации делали. Только это как бы немного... необычно звучит - "вам нужен современный игровой ПК для решения обычных офисных задач - потому что WPF".

А чем VisualBrush помогает при отрисовке графика с большим количеством элементов?

Алексей КТормоза зависят от количества отображаемых элементов на экране, а не от объёма данных, при правильном применении виртуализации.
Если у вас не миллионы записей в гридах и вообще данных не сильно много, то основные тормоза в WPF - именно в отрисовках. Т. е. в количестве элементов и сложности их поведения и вида (анимации есть-нет, градиенты и прозрачность есть-нет, сложные формы и закругления есть-нет, эффекты есть-нет). Чтобы WPF тормозил от данных, а не от отрисовок, надо этих данные миллионами в гриды пихать и юзерконтролы с большой вложенностью делать - это уже действительно кривизна рук.