Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?
Игрушки, hi-perf рендер (конечно, можно захостить 3d-surface, но если 99% вашего приложения — именно сам рендер, от WPF толку не будет), критичные к ресурсам приложения и софт под древние винды/mono, софт, использующий готовый конструктор под win-forms.
Вроде всё. Даже splash на wpf-окошке оказался не сильно тормознутее WinForms-оригинала. На достаточно слабых машинах.
Пару лет назад я бы добавил к списку софт, предназначенный для работы с текстом, но щас ситуация явно улучшилась.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно?
Надо понимать, что WPF — это не API для рисования, а набор решений для построения пользовательского интерфейса. Поэтому, как правильно написал Sinix, если требуется очень много и интенсивно рендерить динамические сцены, WPF сольет по производительности почти всему. Вот статика там хорошо работает: построил сцену и живет она себе, ожидая действий пользователя. А для всяких game-like штуковин лучше Direct2D и т.п.
Здравствуйте, Kerbadun, Вы писали:
X>>кстати вот моя разработка http://gooreader.com, сделанная за 1 мес одним человеком .
K>За 1 мес. — это full-time или по вечерам? А перевертывание страниц в 3D сами делали?
Ну вообще тяжело посчитать затраченное время, делал в свободное от работы, причем очень долго возился с графикой нежели с кодом, ибо рисовать вообще не умею.
страницы — алгоритм не мой.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>>Хотелось-бы все-таки — хороших примеров. Потому как имеющиеся обычно бухгалтеро-ориентированные типа "а мы забиндим коллекцию объектов, она как-то без нас автоматически раскидается, покажется и еще даже можно будет менять" — сильно напоминают своим упрощением действительности якобы простой и удобный PropertyGrid, что, собственно, и настораживает.
N_P>Спасибо всем ответившим!
N_P>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?
Embedded решения; софт, работа которого предполагается из терминальной сессии; серверные утилиты; визуализация больших массивов данных;
Здравствуйте, Visor2004, Вы писали:
N_P>>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?
V>Embedded решения; софт, работа которого предполагается из терминальной сессии; серверные утилиты; визуализация больших массивов данных;
А в чем проблемы с терминальными сессиями и что подразумевается под "серверными утилитами" ?
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Здравствуйте, Visor2004, Вы писали:
N_P>>>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?
V>>Embedded решения; софт, работа которого предполагается из терминальной сессии; серверные утилиты; визуализация больших массивов данных;
N_P>А в чем проблемы с терминальными сессиями и что подразумевается под "серверными утилитами" ?
сложный UI тормозит в терминальных сессиях. Под серверными утилитами подразумевается любой UI работающий на сервере, обычно в сервера ставят такое видео, что странно, что вообще оно хоть что-то рисует.
Здравствуйте, Visor2004, Вы писали:
V>сложный UI тормозит в терминальных сессиях. Под серверными утилитами подразумевается любой UI работающий на сервере, обычно в сервера ставят такое видео, что странно, что вообще оно хоть что-то рисует.
С практической точки зрения: тут у людей проблемы с руками, не с WPF.
С теоретической — всё работает из коробки, начиная с 3.5sp1. Под RDP 7 всё вообще прекрасно. Советую посмотреть "History and background" и ниже.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Visor2004, Вы писали:
V>>сложный UI тормозит в терминальных сессиях. Под серверными утилитами подразумевается любой UI работающий на сервере, обычно в сервера ставят такое видео, что странно, что вообще оно хоть что-то рисует.
S>С практической точки зрения: тут у людей проблемы с руками, не с WPF.
S>С теоретической — всё работает из коробки, начиная с 3.5sp1. Под RDP 7 всё вообще прекрасно. Советую посмотреть "History and background" и ниже.
Ну я ведь не спорю с тем, что если поприседать, то можно добиться приемлемой работы и в терминале, я просто указываю на то, что есть трудности тут.
Здравствуйте, Visor2004, Вы писали:
V>Ну я ведь не спорю с тем, что если поприседать, то можно добиться приемлемой работы и в терминале, я просто указываю на то, что есть трудности тут.
Во-первых, всего приседаний: — _не_ использовать анимации / тяжёлые градиенты с прозрачностью, если WinForms.SystemInformation.TerminalSession = true (по памяти. для wpf — не вспомню).
Во-вторых, с нативным софтом будут ровно те же проблемы.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Поделитесь опытом — а в каких ситуациях WPF НЕ рекомендуется использовать ? Есть ли области применения, где WPF однозначно неудобно ?
Отвечу как троль из КСВ (можно всерьез не воспринимать).
Не рекомендуется использовать WPF в ответственных приложениях, где нужна качественная прорисовка без косяков. Например, не стоит использовать WPF в таких приложениях как Visual Studio 2010.
Ну в окне текстового редактора, конечно кривизну не видно.
Но откройте какую нибудь формочку из студии, например PerfomanceExplorer. Небольшая формочка с графиком, небольшой таблицей. Начинаешь скролить ее по горизонтали. И мало того что тормозит, но все части формы движутся отдельно, одни движутся другие застревают, потом догоняют.
На формочке где большая таблица, при скроллинге заголовок столбцов отделяется от таблицы и движется сам по себе.
В формочке диаграмм классов, если один класс развернуть, потом свернуть, то после этого зум начинает работать так. Картинка нарисованная по центру сначала прыгает в сторону, рисуется там, потом перепрыгивает в центр и снова перерисовывается.
Если кто-то скажет что просто у разработчиков студии руки кривые, просто не умеют правильно готовить WPF. То будет даже смешно.
Быстрая разработка — нашлопали XAML, биндингов и конвертеров, за 5% времени. А остальные 95% времени придумывать как косяки исправить, либо сказать "A .. и так сойдет"
Здравствуйте, Silver_s, Вы писали:
S_> Если кто-то скажет что просто у разработчиков студии руки кривые, просто не умеют правильно готовить WPF. То будет даже смешно.
Можешь не смеяться, но ты просто не стал тратить время на изучение технологии. Те же, кто ее изучил, знает узкие места и научился их обходить. Не в курсе, что там с Performance Explorer, но у нас прога, которая показывает график с более чем 500-ми объектами, каждый из которых рисуется не самой простой геометрией. Чтобы заставить это хорошо работать пришлось потратить время, но я не вижу в этом ничего страшного, потому что технология новая и оптимизировать приходилось, так сказать, эмпирическим путем. Теперь есть багаж знаний и он позволяет ибегать проблем. И не надо здесь рассказывать про Windows Forms, косяки которого вдоль и поперек изучены не одним поколением программистов, начиная с появления WinAPI.
.
