Стоил ли начинать сейчас учить WinForms? - .NET GUI

Здравствуйте, henson, Вы писали:

H>Раз уж товарисч adontz решил поупрямиться отвечу развернуто.
H>Бизнес приложения как раз лучше писать на WPF т.к. элементарно получается быстрей и удобней в разработке

Это не правда. Если сравнивать скорость работы, то XAML редактор оставляет желать лучшего.

H>выглядит современно

Абсолютно нерелевантно.

H>легче модифицировать

Легче модифицировать что?

H>идеологически более правильно.

Опять таки совершенно нерелевантно.

H>В большинстве случаев скорость UI для бизнес приложений в списке приоритетов далеко не на первом месте.

Друг мой, пишуший приложение за три бакса для айфона, скорость работы пользовательского интерфейса бизнес-приложения как раз на самом первом месте. Для склада, кассы, торгового агента реально заметна разница в 100мс во времени отклика.

H>Если нужна скорость или компьютер не тянет WPF, то используется текстовый терминал как при регистрации в аэропорту, но это скорей промышленный use case нежели типичный бизнес.

Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно!

H>Так что пример который привели скорей антипример для WinForms.

Не разбираетесь в вопросе не пишите

Здравствуйте, evo, Вы писали:

evo>Кстати еще оттуда. Сразу не заметил. Почти такой же вопрос как у меня, в каментах внизу (2008 год). Автор отвечает, что однозначно WPF

А можно английский текст? Я там просто не смог найти даже вопрос.

Здравствуйте, adontz, Вы писали:

A>А можно английский текст? Я там просто не смог найти даже вопрос.

http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/

Извините, непонятно написал. Я имел ввиду ту ссылку что вы привели. Два последних сообщения в самом низу (вопрос-ответ).

Здравствуйте, evo, Вы писали:

A>>А можно английский текст? Я там просто не смог найти даже вопрос.
evo>http://joshsmithonwpf.wordpress.com/2007/09/05/wpf-vs-windows-forms/
evo>Извините, непонятно написал. Я имел ввиду ту ссылку что вы привели. Два последних сообщения в самом низу (вопрос-ответ).

Ну во-первых, его спросили не вообще, а про "RIA apps delivered over the internet", а во вторых он ответил что лучше Silverlight использовать.

Здравствуйте, evo, Вы писали:

Я забыл про ещё один момент. Поддержки локализации интерфейсов в WPF прокатически нет. То есть как в WinForms, переключить язык прямо в дизайнере и внести изменения просто нельзя. Вот тут подробнее
http://msdn.microsoft.com/en-us/library/ms746621.aspx

Я знаю, некоторые скажут что это типа правильно отдавать переводчику текстовый файл, а не заставлять его работать в дизайнере VS. Но, его и так никтон е заставлял работать в дизайнере VS, а те кто хоть раз отдавал переводчику просто текстовый файл, знают что не видя контекста использования выражений переводчик выдаёт крайне низкокачественный результат. Элементарно, многие английские слова могут переводится на русский язык как существительное или глагол. Ну и падеж по текстовому файлу тоже не угадаешь.

Здравствуйте, henson, Вы писали:

H>Раз уж товарисч adontz решил поупрямиться отвечу развернуто.
H>Бизнес приложения как раз лучше писать на WPF т.к. элементарно получается быстрей и удобней в разработке, выглядит современно, легче модифицировать и идеологически более правильно.

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

Здравствуйте, adontz, Вы писали:

A>Я знаю, некоторые скажут что это типа правильно отдавать переводчику текстовый файл, а не заставлять его работать в дизайнере VS. Но, его и так никтон е заставлял работать в дизайнере VS, а те кто хоть раз отдавал переводчику просто текстовый файл, знают что не видя контекста использования выражений переводчик выдаёт крайне низкокачественный результат. Элементарно, многие английские слова могут переводится на русский язык как существительное или глагол. Ну и падеж по текстовому файлу тоже не угадаешь.

Тем не менее многие конторы, которые работали с переводами, просто просили ресурсные файлики.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Тем не менее многие конторы, которые работали с переводами, просто просили ресурсные файлики.

Не удивительно, ведь ИМ так удобнее.

Здравствуйте, evo, Вы писали:

evo>Как вы считаете, если сейчас начал изучать .NET и C# стоит ли учить winforms или сразу переходить к WPF. Немножко пробовал winforms и на первый взгляд все просто и логично. С WPF почти не знаком. Читал, что учить значительно труднее. Сложно сделать выбор, когда так мало знаешь. Гуглил этот вопрос и однозначного ответа не нашел. Лично мне было бы интереснее начать с WPF, но не хочется, чтоб получилось так, что много где еще нужны winforms, а я не буду их знать.

WinForms очень прост. Если не писать уж совсем изощренный UI, то и учить там можно сказать практически нечего. MSDN дает ответы на все вопросы буквально на ходу. Конечно же, если знать на память все свойства и методы контролов, то можно лепить UI быстрее и что немаловажно, качественнее. Но тут уже как раз стоит обратить свое внимание на WPF — вот его стоит учить по-настоящему.

Здравствуйте, adontz, Вы писали:

H>>Раз уж товарисч adontz решил поупрямиться отвечу развернуто.
H>>Бизнес приложения как раз лучше писать на WPF т.к. элементарно получается быстрей и удобней в разработке
A>Это не правда. Если сравнивать скорость работы, то XAML редактор оставляет желать лучшего.
Нет, это правда, как ни удивительно. Визуальный редактор WPF — отстой, но в самом XAML писать оказывается гораздо проще и продуктивнее. Я по первости тоже считал, что это будет ужасно, оказалось всё наоборот. Если, скажем, в Windows Forms для переноса контролов выровненных по краям и закрывающих друг друга тебе нужно изловчиться, чтобы выделить их, то в XAML это простое выделение абзаца. Перенос компонентов — простое копирование/перемещение текста. Нереально удобно. И этот отмечали многие, плотно поработав с WPF некоторое время.

H>>легче модифицировать
A>Легче модифицировать что?
Визуальщину. Возможности гораздо богаче. Элементарная задача: захотел заказчик ListBox с элементами по горизонтали, или добавить ComboBox в TreeView. У нас такое было! Как думаешь, сколько у тебя уйдет времени на такое в Windows Forms? А на WPF это час работы, где возня с контролами вообще пять минут.

H>>Если нужна скорость или компьютер не тянет WPF, то используется текстовый терминал как при регистрации в аэропорту, но это скорей промышленный use case нежели типичный бизнес.
A>Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно!
Пробовал? У нас демонстрация проходит в терминальной сессии. Сам боялся, что будет просто ужас. Но нет, скорость получилась хорошая, никто не говорит "а че так медленно".

Здравствуйте, MxMsk, Вы писали:

MM>Нет, это правда, как ни удивительно. Визуальный редактор WPF — отстой, но в самом XAML писать оказывается гораздо проще и продуктивнее. Я по первости тоже считал, что это будет ужасно, оказалось всё наоборот. Если, скажем, в Windows Forms для переноса контролов выровненных по краям и закрывающих друг друга тебе нужно изловчиться, чтобы выделить их, то в XAML это простое выделение абзаца. Перенос компонентов — простое копирование/перемещение текста. Нереально удобно. И этот отмечали многие, плотно поработав с WPF некоторое время.

У редактора XAML проблемы с автодополнением, не говоря уже о том что он регулярно подвисает на 1-2 секунды. Я не вижу что тут можно обсуждать.

A>>Легче модифицировать что?
MM>Визуальщину. Возможности гораздо богаче. Элементарная задача: захотел заказчик ListBox с элементами по горизонтали, или добавить ComboBox в TreeView. У нас такое было! Как думаешь, сколько у тебя уйдет времени на такое в Windows Forms? А на WPF это час работы, где возня с контролами вообще пять минут.

А если тебя попросят поменять цвета выделения: фона и тестка? О-па, во всемогущем WPF цвета выделения прибиты гвоздями, а на WinForms это задача на пять минут. Я не думаю, что меряться решением нетипичных задач плодотворное занятие.

A>>Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно!
MM>Пробовал? У нас демонстрация проходит в терминальной сессии. Сам боялся, что будет просто ужас. Но нет, скорость получилась хорошая, никто не говорит "а че так медленно".

Причём тут домонстрация? Ты видел терминалки на которых одновременно сотня пользователей? Я — да. Никто и не говорил что всё будет тормозить в одной сессии, речь о продкашене.

Здравствуйте, adontz, Вы писали:

MM>>Нет, это правда, как ни удивительно. Визуальный редактор WPF — отстой, но в самом XAML писать оказывается гораздо проще и продуктивнее. Я по первости тоже считал, что это будет ужасно, оказалось всё наоборот. Если, скажем, в Windows Forms для переноса контролов выровненных по краям и закрывающих друг друга тебе нужно изловчиться, чтобы выделить их, то в XAML это простое выделение абзаца. Перенос компонентов — простое копирование/перемещение текста. Нереально удобно. И этот отмечали многие, плотно поработав с WPF некоторое время.
A>У редактора XAML проблемы с автодополнением, не говоря уже о том что он регулярно подвисает на 1-2 секунды. Я не вижу что тут можно обсуждать.
В 2008-й Студии вообще не было толкового intellisense, и тем не менее, редактирование XAML-а все-равно оказывалось удобнее. Этим просто надо реально заниматься, осваивать технику, так сказать.

A>А если тебя попросят поменять цвета выделения: фона и тестка? О-па, во всемогущем WPF цвета выделения прибиты гвоздями, а на WinForms это задача на пять минут. Я не думаю, что меряться решением нетипичных задач плодотворное занятие.
Угу. Как обычно: всё, что на Windows Forms делается сложно — это всё "нетипично". А на WPF даже "прибитые гвоздями" (кстати, не всегда) цвета выделения меняются за пять минут.

A>>>Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно!
MM>>Пробовал? У нас демонстрация проходит в терминальной сессии. Сам боялся, что будет просто ужас. Но нет, скорость получилась хорошая, никто не говорит "а че так медленно".
A>Причём тут домонстрация? Ты видел терминалки на которых одновременно сотня пользователей? Я — да. Никто и не говорил что всё будет тормозить в одной сессии, речь о продкашене.
Если ты пробовал с простейшим UI на WPF и были дикие тормоза, то ок.

Здравствуйте, MxMsk, Вы писали:

A>>У редактора XAML проблемы с автодополнением, не говоря уже о том что он регулярно подвисает на 1-2 секунды. Я не вижу что тут можно обсуждать.
MM>В 2008-й Студии вообще не было толкового intellisense, и тем не менее, редактирование XAML-а все-равно оказывалось удобнее. Этим просто надо реально заниматься, осваивать технику, так сказать.

Есть люди, которые на Си++ пишут в ноутпаде. Я не такой, я себя люблю. У меня, кстати, 2010 SP1, автодополнения нет. Да я не очень крутой спец по WPF и трачу КУЧУ времени на поиск примеров, документации, своего старого кода чтобы понять какими элементами добиться нужной функциональности.

A>>А если тебя попросят поменять цвета выделения: фона и тестка? О-па, во всемогущем WPF цвета выделения прибиты гвоздями, а на WinForms это задача на пять минут. Я не думаю, что меряться решением нетипичных задач плодотворное занятие.
MM>Угу. Как обычно: всё, что на Windows Forms делается сложно — это всё "нетипично". А на WPF даже "прибитые гвоздями" (кстати, не всегда) цвета выделения меняются за пять минут.

Открываем 1С, Dynamics NAV, SAP. Всё чего там нет весьма нетипично. Всё что есть не во всех их них — просто нетипично. Так понятнее?

A>>Причём тут домонстрация? Ты видел терминалки на которых одновременно сотня пользователей? Я — да. Никто и не говорил что всё будет тормозить в одной сессии, речь о продкашене.
MM>Если ты пробовал с простейшим UI на WPF и были дикие тормоза, то ок.

У бизнес-приложений не бывает простейшего UI.

Вообще, когда мы говорим о скорости WPF, подумай вот о чём. Есть куча Widget Library: GTK, wxWidgets, Windows Controls (WinForms обёртка), Qt, HTMLayout, и.т.д. Из всех фреймворков только WPF использует аппартное ускорение по полной. Остальные оптимизируют blit/blend. HTMLayout что-то делает через Direct2D, но DirectX, тем более DirectX 9 не использует больше ни одна библиотека. Справедливости ради, приличных OpenGL based библиотек я тоже не видел. Я могу что-то упустить, но вопрос построения UI для меня важен и я регулярно если не пишу пробный проект, то хотя бы ознакомляюсь по документации. И вот, в WPF, этой крутой библиотеке с самым продвинутым аппаратным ускорением (шейдерными эффектами, етить) есть популярный (часто описываемый в блогах и т.д.) инструмент WPF Performance Suite, который показывает тебе update regions. То есть на доморощеном WinForms перерисовать весь экран не было проблемой, а на супер-крутом WPF — ещё как! Microsoft не выпустили Mole, хотя инструмент нужный и популярный, многие без него как без рук, а вот выделить ресурсы Performance Suite они посчитали правильным. Тебе не кажется, что такое чистосердечное признание заслуживает пристального внимания?

Здравствуйте, adontz, Вы писали:

A>Есть люди, которые на Си++ пишут в ноутпаде. Я не такой, я себя люблю. У меня, кстати, 2010 SP1, автодополнения нет. Да я не очень крутой спец по WPF и трачу КУЧУ времени на поиск примеров, документации, своего старого кода чтобы понять какими элементами добиться нужной функциональности.
Купи книгу по WPF, и пускай она станет твоим учителем. Подходы WPF отличаются от Windows Forms и на первый взгляд вызывают недоумение. А книги тем и хороши, что разъясняют, почему в дизайне библиотеки принято то или иное решение.

MM>>Угу. Как обычно: всё, что на Windows Forms делается сложно — это всё "нетипично". А на WPF даже "прибитые гвоздями" (кстати, не всегда) цвета выделения меняются за пять минут.
A>Открываем 1С, Dynamics NAV, SAP. Всё чего там нет весьма нетипично. Всё что есть не во всех их них — просто нетипично. Так понятнее?
Хорошо. Там есть TextBox-ы со встроенными кнопками? Наверняка. Я заявляю, что на WPF такое сделать: а) проще, б) получится более гибко.

MM>>Если ты пробовал с простейшим UI на WPF и были дикие тормоза, то ок.
A>У бизнес-приложений не бывает простейшего UI.
Ключевое здесь: ты пробовал? Только хочу понять, ты это утверждаешь, проверив реально, или навскидку.

A>Вообще, когда мы говорим о скорости WPF, подумай вот о чём. Есть куча Widget Library: GTK, wxWidgets, Windows Controls (WinForms обёртка), Qt, HTMLayout, и.т.д. Из всех фреймворков только WPF использует аппартное ускорение по полной. Остальные оптимизируют blit/blend. HTMLayout что-то делает через Direct2D, но DirectX, тем более DirectX 9 не использует больше ни одна библиотека. Справедливости ради, приличных OpenGL based библиотек я тоже не видел. Я могу что-то упустить, но вопрос построения UI для меня важен и я регулярно если не пишу пробный проект, то хотя бы ознакомляюсь по документации. И вот, в WPF, этой крутой библиотеке с самым продвинутым аппаратным ускорением (шейдерными эффектами, етить) есть популярный (часто описываемый в блогах и т.д.) инструмент WPF Performance Suite, который показывает тебе update regions. То есть на доморощеном WinForms перерисовать весь экран не было проблемой, а на супер-крутом WPF — ещё как! Microsoft не выпустили Mole, хотя инструмент нужный и популярный, многие без него как без рук, а вот выделить ресурсы Performance Suite они посчитали правильным. Тебе не кажется, что такое чистосердечное признание заслуживает пристального внимания?
WPF проигрывает Windows Forms в скорости рендеринга, я с этим никогда не спорил. Можно даже поискать здесь ветки, гда обсуждался пефоманс, и я приводил пример, который ставит WPF раком. Вопрос в том, насколько это критично в реальном хорошо спроектированном приложении. О WPF Performance Suite я вообще ничего не знаю. И зачем перерисовывать весь экран

Здравствуйте, MxMsk, Вы писали:

A>>Есть люди, которые на Си++ пишут в ноутпаде. Я не такой, я себя люблю. У меня, кстати, 2010 SP1, автодополнения нет. Да я не очень крутой спец по WPF и трачу КУЧУ времени на поиск примеров, документации, своего старого кода чтобы понять какими элементами добиться нужной функциональности.
MM>Купи книгу по WPF, и пускай она станет твоим учителем. Подходы WPF отличаются от Windows Forms и на первый взгляд вызывают недоумение. А книги тем и хороши, что разъясняют, почему в дизайне библиотеки принято то или иное решение.

Да причём тут подходы? Дело в конкретной разметке и отсутсвии автодополнения!

A>>Открываем 1С, Dynamics NAV, SAP. Всё чего там нет весьма нетипично. Всё что есть не во всех их них — просто нетипично. Так понятнее?
MM>Хорошо. Там есть TextBox-ы со встроенными кнопками? Наверняка. Я заявляю, что на WPF такое сделать: а) проще, б) получится более гибко.

То есть в WPF такого контрола нет. Да, WPF нет контрола и в WinForms нет контрола, но в WPF его нет более приятным способом

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

A>>У бизнес-приложений не бывает простейшего UI.
MM>Ключевое здесь: ты пробовал? Только хочу понять, ты это утверждаешь, проверив реально, или навскидку.

Да, я пробовал. Если бы не пробовал, не говорил бы. Ситуация значительно лучше, если Windows Seven SP1 подключается к Windows Server 2008 R2 SP1. Значительно лучше, но эта конфигурация явно не самая распространённая. Впрочем, шейдерный эфект всё равно всё убивает. А они бывают в строниих контролах. То есть вот знаешь купил библиотеку, постетировал, вроде не глючит и делает то, что надо. Написал приложение, протестировали, всё ОК. А потом выясняется что у клиента все сотрудники работают через терминальные сервисы и всё, приехали. А RemoveFX это вообще MS specific, есть ещё всякие цитриксы древних версий, чтоб им пусто было.

MM>WPF проигрывает Windows Forms в скорости рендеринга, я с этим никогда не спорил. Можно даже поискать здесь ветки, гда обсуждался пефоманс, и я приводил пример, который ставит WPF раком. Вопрос в том, насколько это критично в реальном хорошо спроектированном приложении. О WPF Performance Suite я вообще ничего не знаю. И зачем перерисовывать весь экран

Хороше проектирование тут не при чём. Дело в другом. Вот у тебя есть тулбар сверху основного окна. По какой-то причине (шрифт жлемента стал жирным), этот тулбар стал на 1 пиксель (в случае WPF хватит и 0.1 пикселя) выше. Твоё приложение обладает замечательным резиновым интерфейсом (в WinForms в этим реальная жопа, а я как раз сторонник резиновых интерфейсов)и увеличившийся на 1 пиксель тулбар сдвинул всё содержимое окна на 1 пиксель. В HTML это контроллируется через CSS стиль overflow, надо выставить hidden или scroll. В WinForms резиновость задаётся явно, поэтому если ничего не делать тулбар ничего не сдвинет. А вот в WPF у тебя update region будет размером со всё окно. Например, у тебя есть список элементов и пользователь двигается по нему клавишами со стрелками вверх, вниз. А наверху тулбар (или ещё что-то) на котором элементы меняются в зависимости от выделенного элемента. Достаточно типичная ситуаия. Чуть ошибся в разметке и получаешь дикую просадку производительности.

Здравствуйте, adontz, Вы писали:

A>Ну во-первых, его спросили не вообще, а про "RIA apps delivered over the internet", а во вторых он ответил что лучше Silverlight использовать.

Да лопухнулся я. Просто как увидел, что спрашивают:
«So, what would you suggest if we’re just now transitioning over to .NET?»
Потом ответ:
«I would definitely head for WPF.»
Сразу добавил сюда сообщение.

Здравствуйте, adontz, Вы писали:

A>>>Есть люди, которые на Си++ пишут в ноутпаде. Я не такой, я себя люблю. У меня, кстати, 2010 SP1, автодополнения нет. Да я не очень крутой спец по WPF и трачу КУЧУ времени на поиск примеров, документации, своего старого кода чтобы понять какими элементами добиться нужной функциональности.
MM>>Купи книгу по WPF, и пускай она станет твоим учителем. Подходы WPF отличаются от Windows Forms и на первый взгляд вызывают недоумение. А книги тем и хороши, что разъясняют, почему в дизайне библиотеки принято то или иное решение.
A>Да причём тут подходы? Дело в конкретной разметке и отсутсвии автодополнения!
Видимо у твоей Студии какой-то глюк, у меня intellisense действует даже внутри Binding-ов. Ну а книги дают понимание подходов, которое позволяет лучше ориентироваться в XAML, и в том, что нужно написать в конкретном теге.

A>>>Открываем 1С, Dynamics NAV, SAP. Всё чего там нет весьма нетипично. Всё что есть не во всех их них — просто нетипично. Так понятнее?
MM>>Хорошо. Там есть TextBox-ы со встроенными кнопками? Наверняка. Я заявляю, что на WPF такое сделать: а) проще, б) получится более гибко.
A>То есть в WPF такого контрола нет. Да, WPF нет контрола и в WinForms нет контрола, но в WPF его нет более приятным способом

Весьма трезвый взгляд на вещи.
A>Я тебе открою секрет, обычно покупеается какой-нибудь DXperience, так что набор стандартных контролов не очень-то важен.
Тогда непонятны претензии к сложности смены цвета выделения, ведь "покупеается какой-нибудь DXperience" и т.д. Это неконструктивно. Мы здесь сравниваем не сторонние FW и не говнокодинг в стиле "накидал контролов и всё рулит". Далее, ты пробовал добавлять кастом-редакторы в DevExpress-овские контролы? Придется повозиться в коде. В WPF достаточно задать шаблон в XAML. Это намного проще.

A>>>У бизнес-приложений не бывает простейшего UI.
MM>>Ключевое здесь: ты пробовал? Только хочу понять, ты это утверждаешь, проверив реально, или навскидку.
A>Да, я пробовал. Если бы не пробовал, не говорил бы. Ситуация значительно лучше, если Windows Seven SP1 подключается к Windows Server 2008 R2 SP1. Значительно лучше, но эта конфигурация явно не самая распространённая. Впрочем, шейдерный эфект всё равно всё убивает. А они бывают в строниих контролах. То есть вот знаешь купил библиотеку, постетировал, вроде не глючит и делает то, что надо. Написал приложение, протестировали, всё ОК. А потом выясняется что у клиента все сотрудники работают через терминальные сервисы и всё, приехали. А RemoveFX это вообще MS specific, есть ещё всякие цитриксы древних версий, чтоб им пусто было.
Хорошо. Пришли к тому, что в WPF плоховато с обратной совместимостью. Меня это устраивает.

A>Хороше проектирование тут не при чём. Дело в другом. Вот у тебя есть тулбар сверху основного окна. По какой-то причине (шрифт жлемента стал жирным), этот тулбар стал на 1 пиксель (в случае WPF хватит и 0.1 пикселя) выше. Твоё приложение обладает замечательным резиновым интерфейсом (в WinForms в этим реальная жопа, а я как раз сторонник резиновых интерфейсов)и увеличившийся на 1 пиксель тулбар сдвинул всё содержимое окна на 1 пиксель. В HTML это контроллируется через CSS стиль overflow, надо выставить hidden или scroll. В WinForms резиновость задаётся явно, поэтому если ничего не делать тулбар ничего не сдвинет. А вот в WPF у тебя update region будет размером со всё окно. Например, у тебя есть список элементов и пользователь двигается по нему клавишами со стрелками вверх, вниз. А наверху тулбар (или ещё что-то) на котором элементы меняются в зависимости от выделенного элемента. Достаточно типичная ситуаия. Чуть ошибся в разметке и получаешь дикую просадку производительности.
Если тулбар требует сдвига элементов, то в любой технологии это потребует перерисовки всего, что под ним.

Здравствуйте, MxMsk, Вы писали:

MM>Тогда непонятны претензии к сложности смены цвета выделения

У меня нет претензий, я лишь показал что во всех библиотеках есть трудно/неочевидно решаемые нестандартные задачи.

MM>Хорошо. Пришли к тому, что в WPF плоховато с обратной совместимостью. Меня это устраивает.

Тут принципиальная проблема, а не просто с обратной совместимостью. Библиотека основанная на DirectX, в отличие, кстати, от Direct2D, всегда в терминальной сессии будет работать значительно хуже. Это при том что Direct2D умеет использовать DirectX 10.1, но, в отличие от WPF, не умеет использовать WARP10.

Обратная совместимость неправильный термин, тут проблемы с прямой совместимостью. RemoteFX позволил прокидывать через RDP всякие полупрозрачности, но это, во-первых, всего ли одна из технологий, а во-вторых, полупрозрачности не покрывают сложность рендеринга WPF. Трафик стал меньше, время отклика уменьшилось, это да. Но вот нагрузка на процессор от RemoteFX не уменьшилась.

MM>Если тулбар требует сдвига элементов, то в любой технологии это потребует перерисовки всего, что под ним.

Нет. Например, HTMLayout (называю его, потому что больше знаю именно о его внутреностях, наверняка проблема решена и в других библиотеках) будет использовать аппаратный скролл видеокарты. Фактический update region будет только тулбар. Что творится внутри WinForms не знаю, но наличие функции ScrollWindow и кое-какие наблюдения позволяют радоваться за олдскул. Прокрутка области экрана — операция имевшая аппаратную поддержку ещё десять лет тому назад. А WPF, да, ты прав, перерисует весь экран.

Сравнивать статистику снятую летом в период отпусков и зимой это как-то, мягко говоря, некультурно.

Здравствуйте, objMihail, Вы писали:

M>Сравнивать статистику снятую летом в период отпусков и зимой это как-то, мягко говоря, некультурно.

Вообще, сравнение показателей не было основной целью. Основной целью было просто одномоментное получение картинки что и как часто востребовано.
Но все равно, объясните пожалуйста почему "некультурно"?

Здравствуйте, MozgC, Вы писали:

MC>Вообще, сравнение показателей не было основной целью. Основной целью было просто одномоментное получение картинки что и как часто востребовано.

Тогда зачем эти сдвоенные столбики? Именно для сравнения это делалось.

MC>Но все равно, объясните пожалуйста почему "некультурно"?
Ну как бы если для сравнения, то объясняю — создаётся впечатление, что в течении этих ~6 месяцев почти по всем вакансиям C#/Net наблюдается рост, а это на самом деле всего лишь сезонный рост... Как-то так. Это наверное не касается сравнения WinForms и WPF, т.к. видно, что они поменялись местами фактически. Но и это, в принципе, может обуславливаться сезонными особенностями

Здравствуйте, objMihail, Вы писали:

M>Ну как бы если для сравнения, то объясняю — создаётся впечатление, что в течении этих ~6 месяцев почти по всем вакансиям C#/Net наблюдается рост, а это на самом деле всего лишь сезонный рост...
Вы о чем? Какой такой сезонный рост? Я взял случайным образом 100 вакансий (в заголовках которых было либо .NET либо C#, кажется так) в августе и потом 100 вакансий в феврале, смотрел их текст и выписывал то что там упоминается. То, что в большинстве столбиков рост, говорит либо о том, что эти технологии становятся более востребованными, либо о том что работодатели постепенно хотят все больше.
Еще раз — причем тут сезонный рост и отпуска?

Здравствуйте, MozgC, Вы писали:

MC>Я взял случайным образом 100 вакансий (в заголовках которых было либо .NET либо C#, кажется так) в августе и потом 100 вакансий в феврале, смотрел их текст и выписывал то что там упоминается.

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

MC>То, что в большинстве столбиков рост, говорит либо о том, что эти технологии становятся более востребованными, либо о том что работодатели постепенно хотят все больше.
Это было бы так, если бы вы либо в обеих случаях в феврале статистику сняли, либо в августе... но не в разные периоды. Например, вроде так цены акций сравнивают или т.п.

А, сорри, если вы брали в обеих случаях по 100 вакансий, тогда всё конечно меняется и вы правы, а я нет. Но, на графике это всё же желательно было указать, иначе как-то подозрительно.

Здравствуйте, MozgC, Вы писали:

M>>Я взял случайным образом 100 вакансий (в заголовках которых было либо .NET либо C#, кажется так) в августе и потом 100 вакансий в феврале,

Сто ИМХО маловато.

Здравствуйте, adontz, Вы писали:

M>>>Я взял случайным образом 100 вакансий (в заголовках которых было либо .NET либо C#, кажется так) в августе и потом 100 вакансий в феврале,
A>Сто ИМХО маловато.

Ром, я и так одурел от вычитывания 100 вакансий

Ну и повторюсь еще раз — я делал эту картинку чисто для себя, чтобы примерно прикинуть ситуацию, а не проводил полномасштабное научное исследование.
А вообще у вас всех есть возможность сделать свою картинку, с блекджеком и шлюхами

Здравствуйте, MozgC, Вы писали:

MC>Ром, я и так одурел от вычитывания 100 вакансий

Вы читаете вакансии? Тогда мы идём к вам!

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, henson, Вы писали:

H>>Раз уж товарисч adontz решил поупрямиться отвечу развернуто.
H>>Бизнес приложения как раз лучше писать на WPF т.к. элементарно получается быстрей и удобней в разработке
A>Это не правда. Если сравнивать скорость работы, то XAML редактор оставляет желать лучшего.
О мой дорогой клепатель WinForms, прямая верстка с использованием XAML намного быстрей чем таскание контролов по форме. И поддерживать/менять ее намного проще.

H>>выглядит современно
A>Абсолютно нерелевантно.
Только для тех кто не видит разницы между приложениями использующими WPF и MS Access

H>>легче модифицировать
A>Легче модифицировать что?
Продукт

H>>идеологически более правильно.
A>Опять таки совершенно нерелевантно.
Т.е. вы пишите программы как бог на душу положит без всяких MVC/MVP/MVVM?

H>>В большинстве случаев скорость UI для бизнес приложений в списке приоритетов далеко не на первом месте.
A>Друг мой, пишуший приложение за три бакса для айфона, скорость работы пользовательского интерфейса бизнес-приложения как раз на самом первом месте. Для склада, кассы, торгового агента реально заметна разница в 100мс во времени отклика.
Не надо ассоциировать свой опыт написания софта для касс со всеми бизнес приложениями. Вы выбрали довольно специфический use case но, как вы любите выражаться нерелевантный, к теме выбора между WinForms и WPF.

H>>Если нужна скорость или компьютер не тянет WPF, то используется текстовый терминал как при регистрации в аэропорту, но это скорей промышленный use case нежели типичный бизнес.
A>Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно!
А ему там и не место

H>>Так что пример который привели скорей антипример для WinForms.
A>Не разбираетесь в вопросе не пишите

Я то как раз разбираюсь в отличие от

Здравствуйте, henson, Вы писали:

A>>Это не правда. Если сравнивать скорость работы, то XAML редактор оставляет желать лучшего.
H>О мой дорогой клепатель WinForms, прямая верстка с использованием XAML намного быстрей чем таскание контролов по форме. И поддерживать/менять ее намного проще.

Если редактор не зависает и поддерживает автодополнение (то есть в теории) — да.

A>>Абсолютно нерелевантно.
H>Только для тех кто не видит разницы между приложениями использующими WPF и MS Access

Клиентам плевать, так что абсолютно не релевантно. Главное чтобы правильно считало, быстро работало (где это критично) и показывало понятные отчёты.

A>>Легче модифицировать что?
H>Продукт

Не релевантно, если вы, конечно, не делаете интерфейсы полностью вручную.

A>>Опять таки совершенно нерелевантно.
H>Т.е. вы пишите программы как бог на душу положит без всяких MVC/MVP/MVVM?

То есть клиенту плевать что там внутри, если работает.

H>Не надо ассоциировать свой опыт написания софта для касс со всеми бизнес приложениями. Вы выбрали довольно специфический use case но, как вы любите выражаться нерелевантный, к теме выбора между WinForms и WPF.

Простите, но работа кассы или склада не может быть специфичным сценарием в мире товарно-денежных отношений.

A>>Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно!
H>А ему там и не место

А вас не спрашивают куда будут ставить вашу программу, вы на это не влияете. Если я потеряю клиента из-за того что у него развитая инфраструктура виртуализации рабочего места, то мне ни от красоты, ни от идеологической правильности сытнее не будет.

Здравствуйте, adontz, Вы писали:

A>>>Опять таки совершенно нерелевантно.
H>>Т.е. вы пишите программы как бог на душу положит без всяких MVC/MVP/MVVM?

A>То есть клиенту плевать что там внутри, если работает.

H>>Не надо ассоциировать свой опыт написания софта для касс со всеми бизнес приложениями. Вы выбрали довольно специфический use case но, как вы любите выражаться нерелевантный, к теме выбора между WinForms и WPF.

A>Простите, но работа кассы или склада не может быть специфичным сценарием в мире товарно-денежных отношений.

Касса довольно специфический случай с точки зрения программирования. Там выбора между WPF и WinForms может вообще не быть.

A>>>Текстовый терминал? Это шутка? Если уж что-то и применяется помимо компьютера, так это тонкие клиенты для терсиналной сессии. На них Linux или Widnows XP. Уж точно не Seven SP1, да и сервер не 2008 R2 SP1. Как работает WPF завязанный на аппаратное ускорение в терминальной сессии? Как говно!
H>>А ему там и не место

A>А вас не спрашивают куда будут ставить вашу программу, вы на это не влияете. Если я потеряю клиента из-за того что у него развитая инфраструктура виртуализации рабочего места, то мне ни от красоты, ни от идеологической правильности сытнее не будет.

А теперь объясните как это относится к теме выбора между WPF и WinForms?

Здравствуйте, adontz, Вы писали:

A>>>Это не правда. Если сравнивать скорость работы, то XAML редактор оставляет желать лучшего.
H>>О мой дорогой клепатель WinForms, прямая верстка с использованием XAML намного быстрей чем таскание контролов по форме. И поддерживать/менять ее намного проще.
A>Если редактор не зависает и поддерживает автодополнение (то есть в теории) — да.
Знаешь, убеждать людей, которые гораздо больше тебя работают с WPF, в том, что редактировать XAML неудобно и долго — это как-то неправильно.

Здравствуйте, henson, Вы писали:

A>>Простите, но работа кассы или склада не может быть специфичным сценарием в мире товарно-денежных отношений.
H>Касса довольно специфический случай с точки зрения программирования. Там выбора между WPF и WinForms может вообще не быть.

Такой случай вообще выходит за рамки изначального вопроса.

H>А теперь объясните как это относится к теме выбора между WPF и WinForms?

Относится так, что за заявлениями вида "Перспектив у WinForms практически нет, мой голос за WPF" не стоит ничего кроме популизма.

Здравствуйте, MxMsk, Вы писали:

H>>>О мой дорогой клепатель WinForms, прямая верстка с использованием XAML намного быстрей чем таскание контролов по форме. И поддерживать/менять ее намного проще.
A>>Если редактор не зависает и поддерживает автодополнение (то есть в теории) — да.
MM>Знаешь, убеждать людей, которые гораздо больше тебя работают с WPF, в том, что редактировать XAML неудобно и долго — это как-то неправильно.

И все эти топики на connect.microsoft.com и stackoverflow.com сделали мои двойники? Я рад, если конкретно ты не испытываешь проблем, но это никак не отменят того, что разработчики в целом их испытывают.

И да, XAML по сравнению с... да чего далеко ходить, XML со схемой, редактировать крайне неудобно.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, henson, Вы писали:

A>>>Простите, но работа кассы или склада не может быть специфичным сценарием в мире товарно-денежных отношений.
H>>Касса довольно специфический случай с точки зрения программирования. Там выбора между WPF и WinForms может вообще не быть.

A>Такой случай вообще выходит за рамки изначального вопроса.

H>>А теперь объясните как это относится к теме выбора между WPF и WinForms?

A>Относится так, что за заявлениями вида "Перспектив у WinForms практически нет, мой голос за WPF" не стоит ничего кроме популизма.

Тогда понятно. Мой опыт с обоими (WinForms и WPF) зачтен за популизм, твой который выходит за рамки изначального вопроса, рулит и педалит.

Ну успехов

Здравствуйте, henson, Вы писали:

A>>Относится так, что за заявлениями вида "Перспектив у WinForms практически нет, мой голос за WPF" не стоит ничего кроме популизма.
H>Тогда понятно. Мой опыт с обоими (WinForms и WPF) зачтен за популизм, твой который выходит за рамки изначального вопроса, рулит и педалит.

Я показал конкретные сценарии использования, когда WPF сливает. Ты сам признал, что в териминальной сессии WPF делать нечего. Так что я считаю адекватным рассматривать такие однозначные заявления как популизм.

Здравствуйте, adontz, Вы писали:

A>И все эти топики на connect.microsoft.com и stackoverflow.com сделали мои двойники? Я рад, если конкретно ты не испытываешь проблем, но это никак не отменят того, что разработчики в целом их испытывают.
Разработчики "в целом" или те, чьи топики ты нашел, чтобы убедить себя не использовать WPF? Я каждый день бываю на Stack Overflow в темах с тегом WPF, и каждый день я вижу кучу разработчиков осваивающих эту технологию. Процент жалующихся среди ничтожно мал.

A>И да, XAML по сравнению с... да чего далеко ходить, XML со схемой, редактировать крайне неудобно.
Вот и отлично. Пиши GUI на XML схемах.

Здравствуйте, MxMsk, Вы писали:

A>>И да, XAML по сравнению с... да чего далеко ходить, XML со схемой, редактировать крайне неудобно.
MM>Вот и отлично. Пиши GUI на XML схемах.

Это называется XHTML

Здравствуйте, MxMsk, Вы писали:

MM>Разработчики "в целом" или те, чьи топики ты нашел, чтобы убедить себя не использовать WPF? Я каждый день бываю на Stack Overflow в темах с тегом WPF, и каждый день я вижу кучу разработчиков осваивающих эту технологию. Процент жалующихся среди ничтожно мал.

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

Здравствуйте, adontz, Вы писали:

A>Тормоза редактора никак не коррелируют с уровнем владения технологии. Мне записать тебе скринкаст с тормозящим редактором XAML или ты всё-таки признаешь очевидные факты, подтверждённые многократными свидетельствами разных людей?
Нет, спасибо. Мне это не нужно — я уже перешел на WPF.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, evo, Вы писали:

A>Существует распространённое заблуждение, что WPF может полностью заменить Windows Forms. В общем случае это не так. Бизнес-приложения (толстые клиенты трёхзвенок), лучше писать на Windows Forms, так как элементарно быстрее работает, а эффекты на шейдерах не нужны.

Имхо заблуждение что WinForm работает быстрее нужно еще учесть что
1) WinForm которая работает через GDI будет работать медленнее т.к. все что работает через GDI работает медленнее чем через DirectX.
Даже стандартные кнопки кому-то нужно рисовать, GDI прямоугольник с текстом будет рисовать на порядок дольше чем аналог через DirectX.
2) WinForm съедает больше памяти т.к. на каждый созданный объект расходуется память на все свойства объекта, в WPF только на измененные свойства, отличные от тех что по умолчанию ( которые attached и dependency ).

Здравствуйте, Аноним, Вы писали:

А>все что работает через GDI работает медленнее чем через DirectX.

Вы не имеете ни малейшего понятия как работает видеокарта.

Здравствуйте, henson, Вы писали:

H>Ну успехов
Мне вообще теперь кажется, что весь топик для adontz'а был чисто поржать. А что, судя по смайликам, ни один ответ он всерьез не воспринял

Здравствуйте, MxMsk, Вы писали:

MM>Мне вообще теперь кажется, что весь топик для adontz'а был чисто поржать. А что, судя по смайликам, ни один ответ он всерьез не воспринял

Дорогой Марат, ты сперва внедри приложение с компании с >100 рабочих мест и инфрастуктурой проектировки 5-летней давности, а потом мы поговорим о том как это ржачно.

Моё личное мнение заключается в том что:
1) WinForms — ужасно. Причём даже не WinForms, а оконная система Windows, которую WinForms оборачивает и немножечко улучшает (как и MFC). Делать нестандартные элементы управления трудоёмко, делать резиновые интерфейсы трудоёмко.
2) WPF — перспективная система. Я не считаю что она перешла в состояние mature, к 5-6 версии будет окончательно понятно куда она двигается. Но уже можно пользоваться.
3) Ничего лучше HTML + CSS человечество пока не придумало. Я бы с огромным удовольствием делал все интерфейсы на HTML, если бы текущие движки не интегрировались с .Net так плохо.
4) Моё мнение в трх предыдущих пуктах никого на хер не волнует. Надо писать то, что потом можно безболезненно внедрить. Важна полная стоимость владения и интеграторы могут отыгрываться за счёт программистов, требуя программы работающие в устаревших, нестандартных, ограниченных средах. Это нормально, так устроен бизнес. Я уже не раз переступал через себя, создавая идеологически неправильные решения. И ещё не раз переступлю, потому что идеологически правильные решения обходились в конечном итоге дороже, а желание кушать приоритетнее желания гордиться собой.

Давай я тебе объясню проще, с описанием тех этапов, которые тебе, как программисту, не видны.

Хороший, но идеологически неправильный, сценарий:
1) Создать приложение на WinForms — 1000 человеко-часов.
2) Внедрили в срок. Потрачено 1000 часов программистов, все довольны.

Плохой, но идеологически правильный, сценарий:
1) Создать приложение на WPF — 300 человеко-часов.
2) Объяснить менеджменту клиента почему старая программа не тормозила, а новая тормозит. Вероятность потерять контракт — 35%.
3) Оптимизировать конкретные окна WPF приложения, вычищая всю ту красоту, которую раньше наворотили — 100 человеко-часов.
4) Обновить драйвера видеокарты на всех целевых компьютерах — 200 человеко-часов.
5) Объяснить менеджменту клиента зачем это было надо.
6) Узнать что из 100 компьютеров на 20 программа вообще не запуститься и их надо заменять...
7) Объяснить менеджменту клиента зачем это надо, подобрать минимальную (самую дешёвую) конфигурацию. Трата незапланированная, финансовый менеджер смотрит на вас как на врагов.
8) С ужасом обнаружить что сама дешёвая конфигурация, пожалуй, слишком дешёвая.
9) Оптимизировать конкретные окна WPF приложения, вычищая всю ту красоту, которую раньше наворотили, чтобы работано на самой дешёвой конфигурации, — 200 человеко-часов.
10) Выяснить что ест удалённый офис в крыжопинске откуда заходят по терминальной сессии. Пообщаться с сисадмином который категорически откажется что-либо менять. Будет представлено множество обоснований: мнешных для вас, весомых для его начальства. Многократно прозвучат слова безопасностьи стабильность.
11) Надо покупать новый терминальный сервер/менять процессов в старом. Сервер скорее всего с процессором Intel. Это вам не AMD, где в материнку трёхлетней давности можно запросто воткнуть новый процессор и запустить его перепрошив БИОС. Придётся менять с процессором материнку и память. И винчестеры, потому что HP. Финансовый директор ведёт себя вызывающе, откровенно подтрунивает над навыками планирования и бюджетирования.
12) Кое-как внедрили с опозданием. Потрачено 600 часов программистов, 200 админов, миллиарды мёртвых клеток в головном мозге менеджмента. Клиент не особо доволен, финансового менеджера вы избегаете.

Здравствуйте, adontz, Вы писали:

A>Дорогой Марат, ты сперва внедри приложение с компании с >100 рабочих мест и инфрастуктурой проектировки 5-летней давности, а потом мы поговорим о том как это ржачно.
Хорошо.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, MxMsk, Вы писали:

MM>>Мне вообще теперь кажется, что весь топик для adontz'а был чисто поржать. А что, судя по смайликам, ни один ответ он всерьез не воспринял

A>Дорогой Марат, ты сперва внедри приложение с компании с >100 рабочих мест и инфрастуктурой проектировки 5-летней давности, а потом мы поговорим о том как это ржачно.

А нахрена в такой ситуации внедрять чтонить кроме веб-решений с его html\css?

Здравствуйте, gandjustas, Вы писали:

G>А нахрена в такой ситуации внедрять чтонить кроме веб-решений с его html\css?

Часто приходится общатся с разной аппаратурой.
1) Печатать сразу на нескольких принтерах в рамках оформления одного документа: счёт-фактуру на матричном, чтобы пробило на все страницы (там копирка), накладную на лазерном, стикер для коробки с товаром на термопринтере.
2) Получать данные со сканеров штрихкода сидящих на СОМ порту (да такой ужас ещё встречается).
3) Бывают случаи, когда надо уметь отличать ввод одних и тех же данных (последовательности символов) между клавиатурой и USB сканером.

Время отклика очень важно опять же. Реальный случай. Складские работники жаловались на время отклика при сканировании. А склад это вообще место очень бурной деятельности. По утрам писки от сканеров штрихкодов сливаются в непрерывный звук. Им уже всё вылизали как могли. Так вот, эти товарищи замечали смену размера MTU. А от склада до серверов была выделенная волоконно-оптическая гигабитная линия. И вот им подобрали такой MTU, чтобы пакеты не фрагментировались и они это заметили. То есть сами(!) позвонили и спросили "У нас лучше стало работать, вы что-то поменяли?". Я бы не поверил, если бы не присутствовал сам.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>А нахрена в такой ситуации внедрять чтонить кроме веб-решений с его html\css?

A>Часто приходится общатся с разной аппаратурой.
A>1) Печатать сразу на нескольких принтерах в рамках оформления одного документа: счёт-фактуру на матричном, чтобы пробило на все страницы (там копирка), накладную на лазерном, стикер для коробки с товаром на термопринтере.
A>2) Получать данные со сканеров штрихкода сидящих на СОМ порту (да такой ужас ещё встречается).
A>3) Бывают случаи, когда надо уметь отличать ввод одних и тех же данных (последовательности символов) между клавиатурой и USB сканером.
А как же кейс с удаленным рабочим столом?
Веб-интерфейс удовлетворит 99% пользователей, а оставшийся 1% можно покрыть другими способами: activex или отдельное приложение.

A>Время отклика очень важно опять же. Реальный случай. Складские работники жаловались на время отклика при сканировании. А склад это вообще место очень бурной деятельности. По утрам писки от сканеров штрихкодов сливаются в непрерывный звук. Им уже всё вылизали как могли. Так вот, эти товарищи замечали смену размера MTU. А от склада до серверов была выделенная волоконно-оптическая гигабитная линия. И вот им подобрали такой MTU, чтобы пакеты не фрагментировались и они это заметили. То есть сами(!) позвонили и спросили "У нас лучше стало работать, вы что-то поменяли?". Я бы не поверил, если бы не присутствовал сам.

Отзывчивость интерфейса зависела от латентности сетевого взаимодействия? Видимо надо было асинхронные сетевые вызовы делать. В вебе кстати так и делают.

Здравствуйте, gandjustas, Вы писали:

A>>1) Печатать сразу на нескольких принтерах в рамках оформления одного документа: счёт-фактуру на матричном, чтобы пробило на все страницы (там копирка), накладную на лазерном, стикер для коробки с товаром на термопринтере.
A>>2) Получать данные со сканеров штрихкода сидящих на СОМ порту (да такой ужас ещё встречается).
A>>3) Бывают случаи, когда надо уметь отличать ввод одних и тех же данных (последовательности символов) между клавиатурой и USB сканером.
G>А как же кейс с удаленным рабочим столом?

RDP позволяет прокидывать принтеры (несколько) и порты. Для принтеров есть ещё ThinPrint.

G>Веб-интерфейс удовлетворит 99% пользователей, а оставшийся 1% можно покрыть другими способами: activex или отдельное приложение.

Ну знаешь, нет никакого смысла писать веб И отдельное приложение. Это разнопрофильные группы разработчиков и многие другие проблемы.

G>Отзывчивость интерфейса зависела от латентности сетевого взаимодействия? Видимо надо было асинхронные сетевые вызовы делать. В вебе кстати так и делают.

Приложение находится в терминальной сессии.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>1) Печатать сразу на нескольких принтерах в рамках оформления одного документа: счёт-фактуру на матричном, чтобы пробило на все страницы (там копирка), накладную на лазерном, стикер для коробки с товаром на термопринтере.
A>>>2) Получать данные со сканеров штрихкода сидящих на СОМ порту (да такой ужас ещё встречается).
A>>>3) Бывают случаи, когда надо уметь отличать ввод одних и тех же данных (последовательности символов) между клавиатурой и USB сканером.
G>>А как же кейс с удаленным рабочим столом?

A>RDP позволяет прокидывать принтеры (несколько) и порты.
То что можно так делать, не значит что нужно.

G>>Веб-интерфейс удовлетворит 99% пользователей, а оставшийся 1% можно покрыть другими способами: activex или отдельное приложение.

A>Ну знаешь, нет никакого смысла писать веб И отдельное приложение. Это разнопрофильные группы разработчиков и многие другие проблемы.
Как раз-таки смысл есть. Отдельное приложение общается с сервером и вся логика находится там. На клиенте только простой интерфейс и взаимодействие с железками.
Сейчас вообще есть отличная возможность с out-of-browser silverlight в elevated режиме. Можно и печатать и com вызывать, и веб, и не нужны терминальные сессии.

G>>Отзывчивость интерфейса зависела от латентности сетевого взаимодействия? Видимо надо было асинхронные сетевые вызовы делать. В вебе кстати так и делают.
A>Приложение находится в терминальной сессии.

Здравствуйте, gandjustas, Вы писали:

A>>RDP позволяет прокидывать принтеры (несколько) и порты.
G>То что можно так делать, не значит что нужно.

В действительности, бывает что нужно. Если, например, используется ThinPrint.

A>>Ну знаешь, нет никакого смысла писать веб И отдельное приложение. Это разнопрофильные группы разработчиков и многие другие проблемы.
G>Как раз-таки смысл есть. Отдельное приложение общается с сервером и вся логика находится там. На клиенте только простой интерфейс и взаимодействие с железками.
G>Сейчас вообще есть отличная возможность с out-of-browser silverlight в elevated режиме. Можно и печатать и com вызывать, и веб, и не нужны терминальные сессии.

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

G>>>Отзывчивость интерфейса зависела от латентности сетевого взаимодействия? Видимо надо было асинхронные сетевые вызовы делать. В вебе кстати так и делают.
A>>Приложение находится в терминальной сессии.
G>

Ну да, представь себе что отзывчивость терминальной сессии зависит от MTU настолько, что это заметно человеку.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Ну знаешь, нет никакого смысла писать веб И отдельное приложение. Это разнопрофильные группы разработчиков и многие другие проблемы.
G>>Как раз-таки смысл есть. Отдельное приложение общается с сервером и вся логика находится там. На клиенте только простой интерфейс и взаимодействие с железками.
G>>Сейчас вообще есть отличная возможность с out-of-browser silverlight в elevated режиме. Можно и печатать и com вызывать, и веб, и не нужны терминальные сессии.

A>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают.

Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов. Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером.

Здравствуйте, evo, Вы писали:

evo>Как вы считаете, если сейчас начал изучать .NET и C# стоит ли учить winforms или сразу переходить к WPF. Немножко пробовал winforms и на первый взгляд все просто и логично. С WPF почти не знаком. Читал, что учить значительно труднее. Сложно сделать выбор, когда так мало знаешь. Гуглил этот вопрос и однозначного ответа не нашел. Лично мне было бы интереснее начать с WPF, но не хочется, чтоб получилось так, что много где еще нужны winforms, а я не буду их знать.

Винформы до безобразия просты, хватит буквально одной недели чтобы изучить все, причем большую часть времени ты потратишь на databinding и grid.
WPF гораздо сложнее, библиотека классов побольше и возможностей больше на порядок, кроме того подмножество WPF используется в Silverlight и Windows Phone 7, поэтому изучать его обязательно. Кстати начинать изучать я бы рекомендовал именно с Silverlight.

Здравствуйте, gandjustas, Вы писали:

A>>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают.
G>Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов.

Честно говоря, я даже не понял что ты хотел сказать.

G>Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером.

ИМХО это решение может быть оптимально при командах от 10 выделенных разработчиков на проект.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают.
G>>Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов.
A>Честно говоря, я даже не понял что ты хотел сказать.
В этом и проблема. Надо это понимать.

G>>Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером.
A>ИМХО это решение может быть оптимально при командах от 10 выделенных разработчиков на проект.
Я один поднимал такое решение.

Здравствуйте, gandjustas, Вы писали:

A>>>>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают.
G>>>Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов.
A>>Честно говоря, я даже не понял что ты хотел сказать.
G>В этом и проблема. Надо это понимать.

Напустить на себя таинственность ты сумел, теперь расскажи по существу почему WinForms и WPF одинаково плохо подходят для терминальной сессии.

G>>>Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером.
A>>ИМХО это решение может быть оптимально при командах от 10 выделенных разработчиков на проект.
G>Я один поднимал такое решение.

Решения которые может создать один программист вообще не интересно рассматривать.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>>>Терминальные сессии нужны по многим причинам. В плане железо+лицензии рабочее место может обходится даже немного дороже, выгода там в простоте администрирования. Ну и в любом случае, это не программисты решают.
G>>>>Суть в том что обе рассматриваемые технологии winforms и wpf для решения таких задач подходят крайне плохо. Первая по причине ущербности, вторая по причине прожорливости, обе по сложности установки\обновления или использованию терминалов.
A>>>Честно говоря, я даже не понял что ты хотел сказать.
G>>В этом и проблема. Надо это понимать.

A>Напустить на себя таинственность ты сумел, теперь расскажи по существу почему WinForms и WPF одинаково плохо подходят для терминальной сессии.
Вообще терминальная сессия плохо подходит для решения бизнес-задач, независимо от того что там крутится. Повышенная нагрузка на сеть, ограничение на UI, доступно далеко не с любого устройства, сложно масштабировать\балансировать нагрузку, повышенные административные затраты на управление правами пользователей. Короче дофига недостатков, которые в вебе не появляются вообще никак.

G>>>>Как я уже говорил решение на вебе подойдет в подавляющем большинстве случаев, там где не хватит возможностей html\css\js можно подключить sl\flash\activex\java, самый крайняк использовать отдельное приложение которое общается с сервером.
A>>>ИМХО это решение может быть оптимально при командах от 10 выделенных разработчиков на проект.
G>>Я один поднимал такое решение.

A>Решения которые может создать один программист вообще не интересно рассматривать.
А какая разница? Если у меня хватило навыков чтобы создать веб-приложение, которое работает на десктопе, на киоске с тачскрином и на мобильном устройстве, а также написать на SL код, который позволил печатать на киоске и на десктопе то что нужно, то почему другой программист не сможет такое сделать? Если будет больше одного такого программиста, то результат будет только лучше.

Здравствуйте, gandjustas, Вы писали:

G> Повышенная нагрузка на сеть

Это неправда. Нагрузка, в действительности, снижается. Есть некоторый порог, после которого объём изменений видеокадра меньше объёма обрабатываемых данных. К тому же отпадает вопрос о постраничном выводе как таковой. Ч терминалом можно (правда плохо, но можно) работать даже через GPRS.

G> ограничение на UI

По сравнению с чем? Ты утверждаешь что веб (HTML или Silverlight) лучше WinForms или WPF. Разница между Silverlight и WPF не заметна в микроскоп. Веб-браузер не даст тебе свободы в UI. Даже клавиатурное сокращение толком назначить нельзя. Про принтеры я уже говорил.

G> доступно далеко не с любого устройства

Silverlight или продвинутый движок HTML тоже.

G> сложно масштабировать\балансировать нагрузку

Это неправда. Ставишь второй терминал, настраиваешь NLB, забываешь о проблеме. Я работал с фермами терминалов, никакой проблемы масштабирования там нет.

G> повышенные административные затраты на управление правами пользователей.

Тоже не правда. Наоборот, в среде развитого домена Active Directory тебе вообще не надо что-либо настраивать, потому что все пользователи уже есть, уже объединены в группы и т.д.

G> Короче дофига недостатков, которые в вебе не появляются вообще никак.

В общем ты просто не умеешь их готовить.

A>>Решения которые может создать один программист вообще не интересно рассматривать.
G>А какая разница? Если у меня хватило навыков чтобы создать веб-приложение, которое работает на десктопе, на киоске с тачскрином и на мобильном устройстве, а также написать на SL код, который позволил печатать на киоске и на десктопе то что нужно, то почему другой программист не сможет такое сделать? Если будет больше одного такого программиста, то результат будет только лучше.

Сколько стоит программист у которого хватит навыков? Сколько стоят два таких программиста (один мало, риски)? Зачем платить больше?

Здравствуйте, gandjustas, Вы писали:

G>Кстати начинать изучать я бы рекомендовал именно с Silverlight.
Я бы не рекомендовал. Оно безумно урезано, особенно SL 3. То, что в WPF решается не задумываясь, в SL регулярно превращается в ругань и гору костылей.

DataTrigger-ы, команды, multibinding, FlowDocument, {DynamicResource}, биндинг к xpath, объединение ресурсов, наследование стилей — это только то, что я с ходу вспомнил; если покопаться — наберу раза в 2 больше. Большей части нет в SL4 и даже в 5. Ну и нафига?

A>Дорогой Марат, ты сперва внедри приложение с компании с >100 рабочих мест и инфрастуктурой проектировки 5-летней давности, а потом мы поговорим о том как это ржачно.

Рецепт от adontz: выбрать технологию неподходящую для чего-либо и на этом основании раскритиковать ее целиком забив на все остальные возможности применения.

Как насчет того, чтобы сравнивать WinForms и WPF там где ОБЕ технологии уместны?

Здравствуйте, henson, Вы писали:

H>Как насчет того, чтобы сравнивать WinForms и WPF там где ОБЕ технологии уместны?

Я уже ответил на этот вопрос. Если бы ты читал мои сообщения, то заметил бы это.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>> Повышенная нагрузка на сеть
A>Это неправда. Нагрузка, в действительности, снижается. Есть некоторый порог, после которого объём изменений видеокадра меньше объёма обрабатываемых данных.
У нас видимо разные "действительности". Веб + ajaj + json + http compression, и меньше передавать уже вряд ли получится. Около килобайта на раундтрип при очень data-intensive приложении. Еще и клиентское кеширование есть.

A>К тому же отпадает вопрос о постраничном выводе как таковой.
Не отпадает потому что постраничный нужен в первую очередь для человека.

A>Ч терминалом можно (правда плохо, но можно) работать даже через GPRS.
Очень плохо, но можно — считай нельзя.

G>> ограничение на UI
A>По сравнению с чем? Ты утверждаешь что веб (HTML или Silverlight) лучше WinForms или WPF.
Угу, потому что работает на любой оси и на мобильных устройствах.

A>Разница между Silverlight и WPF не заметна в микроскоп.
Ты видимо очень много на SL писал что так утверждаешь.

A>Веб-браузер не даст тебе свободы в UI. Даже клавиатурное сокращение толком назначить нельзя.
Перехватывай нажатие клавиш и обрабатывай, в чем проблема?

G>> доступно далеко не с любого устройства
A>Silverlight или продвинутый движок HTML тоже.

Да ну? HTML4 доступен чуть менее чем везде, HTML 5 доступен на любом десктопе. А что насчет remote desktop?

G>> сложно масштабировать\балансировать нагрузку
A>Это неправда. Ставишь второй терминал, настраиваешь NLB, забываешь о проблеме. Я работал с фермами терминалов, никакой проблемы масштабирования там нет.

Это на словах просто, а на деле не каждый админ потянет. По сравнению с масштабированием веб-решений на порядок сложнее.

G>> повышенные административные затраты на управление правами пользователей.
A>Тоже не правда. Наоборот, в среде развитого домена Active Directory тебе вообще не надо что-либо настраивать, потому что все пользователи уже есть, уже объединены в группы и т.д.
Я не про AD, его можно и в вебе использовать, я про разрешения на сервере терминалов и в приложении.

G>> Короче дофига недостатков, которые в вебе не появляются вообще никак.
A>В общем ты просто не умеешь их готовить.

Недостатки? Конечно!

A>>>Решения которые может создать один программист вообще не интересно рассматривать.
G>>А какая разница? Если у меня хватило навыков чтобы создать веб-приложение, которое работает на десктопе, на киоске с тачскрином и на мобильном устройстве, а также написать на SL код, который позволил печатать на киоске и на десктопе то что нужно, то почему другой программист не сможет такое сделать? Если будет больше одного такого программиста, то результат будет только лучше.

A>Сколько стоит программист у которого хватит навыков? Сколько стоят два таких программиста (один мало, риски)? Зачем платить больше?
Ну программисты на вебе, как ни странно, стоят дешевле админов, умеющих NLB поднимать.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Кстати начинать изучать я бы рекомендовал именно с Silverlight.
S>Я бы не рекомендовал. Оно безумно урезано, особенно SL 3. То, что в WPF решается не задумываясь, в SL регулярно превращается в ругань и гору костылей.
Дык если изучать, то SL5.

S>DataTrigger-ы, команды, multibinding, FlowDocument, {DynamicResource}, биндинг к xpath, объединение ресурсов, наследование стилей — это только то, что я с ходу вспомнил; если покопаться — наберу раза в 2 больше. Большей части нет в SL4 и даже в 5. Ну и нафига?
1)Большинство нафиг не нужно
2)SL это не только веб, но и windows phone
3)SL используется сейчас гораздо чаще WPF

ЗЫ. Мне вообще-то искренне жаль людей, которые сначала освоили WPF, а потом пересели на SL.

Здравствуйте, adontz, Вы писали:

H>>Как насчет того, чтобы сравнивать WinForms и WPF там где ОБЕ технологии уместны?
A>Я уже ответил на этот вопрос. Если бы ты читал мои сообщения, то заметил бы это.
Не, ну ведь правда. Ты привел в пример свою ситуацию, в которую тебе сложно вписать WPF, и предлагаешь нам смотреть на всё сквозь призму этого проекта. Да, я не участвовал в подобных разработках, поэтому по существу на твой пример ответить мне нечего. Но зато было штук семь других внедренных проектов, в которых переход на WPF, насколько я знаю, запланирован. И я уверен, что там он не вызовет проблем. Во многом еще и потому, что заказчики готовы платить за упрощение поддержки решения, к чему в итоге приведет внедрение WPF. Однако, по твоей логике получается, что этого делать не нужно. Причем если мы отбросим пример с терминалом, которого в данном случае нет, то причины для этого "редактор XAML тормозит, intellisense не работает, книжку купить влом".

Здравствуйте, gandjustas, Вы писали:

G>У нас видимо разные "действительности". Веб + ajaj + json + http compression, и меньше передавать уже вряд ли получится. Около килобайта на раундтрип при очень data-intensive приложении. Еще и клиентское кеширование есть.

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

A>>К тому же отпадает вопрос о постраничном выводе как таковой.
G>Не отпадает потому что постраничный нужен в первую очередь для человека.

Нет нужды в постраничной загрузке и нет нужды в постраничном выводе. При поиске картинок в Гугле постраничного вывода нет. Когда-нибудь постраничный вывод умрёт. Он не нужен людям, он нужет был исключительно для минимизации трафика во времена когда нельзя было подгружать без перезагрузки страницы.

A>>С терминалом можно (правда плохо, но можно) работать даже через GPRS.
G>Очень плохо, но можно — считай нельзя.

Про очень никто не говорил. Подтормаживать иногда будет, но работать вполне возможно. Разница заметна, но не катастрофична.

A>>По сравнению с чем? Ты утверждаешь что веб (HTML или Silverlight) лучше WinForms или WPF.
G>Угу, потому что работает на любой оси и на мобильных устройствах.

Ой, ну это просто сказки. Под Windows Силверлайт четвёртый, под MacOS третий, под Linux какой-то Мунлайт, который непонятно чему соответствует, под Android и iOS Силверлайта нет. При этом даже четвёртый так убог, что ты советуешь учить пятый.

A>>Разница между Silverlight и WPF не заметна в микроскоп.
G>Ты видимо очень много на SL писал что так утверждаешь.

Я правильно ттебя понял, что на Силверлайте писать удобнее, чем на WPF? Если я и ошибаюсь, то явно не в пользу твоих уверждений.

A>>Веб-браузер не даст тебе свободы в UI. Даже клавиатурное сокращение толком назначить нельзя.
G>Перехватывай нажатие клавиш и обрабатывай, в чем проблема?

В том что, например, Ctrl+D в файрфоксе создаёт закладку и хоть ты и можешь получить сообщение о том что Ctrl+D нажата, отменить действие по умолчанию ты не можешь. Когда я последний раз смотрел в оОпере было тоже самое. А сколько у нас ещё разных юраузеров разных версий? Везде свободных клавиатурных сочетаний крайне мало.

A>>Silverlight или продвинутый движок HTML тоже.

G>Да ну? HTML4 доступен чуть менее чем везде, HTML 5 доступен на любом десктопе. А что насчет remote desktop?

Вот как раз Remote Desktop действительно везде доступен. Все версии Windows, все версии Windows Mobile, Windows Phone 7, MacOS, Linux. Причём пользователь получит абсолютно одинаковый UX и не надо думать об особенностях ОС на которйо он сидит. По факту RDP доступен на большем количестве платформе, чем Silverlight.

A>>Это неправда. Ставишь второй терминал, настраиваешь NLB, забываешь о проблеме. Я работал с фермами терминалов, никакой проблемы масштабирования там нет.
G>Это на словах просто, а на деле не каждый админ потянет. По сравнению с масштабированием веб-решений на порядок сложнее.

Ой, ну что за глупости. Любая подобная балансировка нагрущзки под Windows делается через NLB, будет это 80й порт или 3389 порт, значения не имеет. Тот кто сделает одно, сделает и другое.

A>>Тоже не правда. Наоборот, в среде развитого домена Active Directory тебе вообще не надо что-либо настраивать, потому что все пользователи уже есть, уже объединены в группы и т.д.
G>Я не про AD, его можно и в вебе использовать, я про разрешения на сервере терминалов и в приложении.

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

A>>Сколько стоит программист у которого хватит навыков? Сколько стоят два таких программиста (один мало, риски)? Зачем платить больше?
G>Ну программисты на вебе, как ни странно, стоят дешевле админов, умеющих NLB поднимать.

Ты заблуждаешься. NLB поднять — пятиминутное дело.

Здравствуйте, gandjustas, Вы писали:

S>>DataTrigger-ы, команды, multibinding, FlowDocument, {DynamicResource}, биндинг к xpath, объединение ресурсов, наследование стилей — это только то, что я с ходу вспомнил; если покопаться — наберу раза в 2 больше. Большей части нет в SL4 и даже в 5. Ну и нафига?
G>1)Большинство нафиг не нужно
Тут не КСВ и "___ не нужен" — ни разу не довод. Плиз, давайте будем обосновывать своё мнение

G>2)SL это не только веб, но и windows phone
Угумс. Проблема в том, что мне периодически стучится в аську товарищ, занимаюшийся разработкой под WP7.
С самыми элементарными вопросами — как выровнять текст по ширине, как использовать compiled-регэксы, как захостить flow document, как показать gif, как прибиндиться с {RelativeSource AncestorType}, как поставить биндинг в стиле, как менять картинку в зависимости от значения нескольких свойств, как динамически менять оформление...

Я тоже должен был отвечать — оно всё не нужно?

G>ЗЫ. Мне вообще-то искренне жаль людей, которые сначала освоили WPF, а потом пересели на SL.
Аналогично.

Здравствуйте, MxMsk, Вы писали:

A>>Я уже ответил на этот вопрос. Если бы ты читал мои сообщения, то заметил бы это.
MM>Не, ну ведь правда. Ты привел в пример свою ситуацию, в которую тебе сложно вписать WPF, и предлагаешь нам смотреть на всё сквозь призму этого проекта. Да, я не участвовал в подобных разработках, поэтому по существу на твой пример ответить мне нечего. Но зато было штук семь других внедренных проектов, в которых переход на WPF, насколько я знаю, запланирован. И я уверен, что там он не вызовет проблем. Во многом еще и потому, что заказчики готовы платить за упрощение поддержки решения, к чему в итоге приведет внедрение WPF.

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

MM>Однако, по твоей логике получается, что этого делать не нужно. Причем если мы отбросим пример с терминалом, которого в данном случае нет, то причины для этого "редактор XAML тормозит, intellisense не работает, книжку купить влом".

По моей логике получается, что случаи бывают разные и не надо кричать "А-а-а-а, все учите WPF, лучше консоль, чем WinForms!", это не адекватно. Есть большие сектора разработки ПО в которых красота интерфейса далеко не на первом месте. Я своими глазами видел Dynamics NAV и меня от него тошнит. Я своими глазами видел 1С, в базовой конфигурации терпимо, но после переделок франчиз он может быть просто ужасен. За них платят миллионы. Я делаю выводы о важности красивого интерфейса для некоторых весьма платежеспособных категорий заказчиков. Байндинг из коробки в WPF лучше, всякие MVVM прикрутить проще. Вопрос только в том, чтобы не зацикливаться на технологиях. У меня сейчас есть программа просто сказка. WinForms, да, но один из лучших экземпляров. Красивый интерфейс, оптимизирован под разботу с клавиатурой, на трёх языках, везде автодополнение, цветовая индикация. Всё гармонично, качественный дизайн. А у клиента стоит программа на одном языке (причём не государственном), с существенно меньшим функционалом и... в ней нет двух кнопок одинакового размера, нет двух полей одинакового размера. Окна программы это хаотичные нагромождения элементов управления. Но старая программа им нравится! И я свою лапочку переделываю в говно, потому что они так привыкли. Вот эта жопа и есть реалии бизнеса. Интересует меня в такой ситуации крутой бандинг в WPF? Ничуть.

P.S. XAML редактор тормозит. Честно-честно. Это заметный минус, но, конечно, не фатальный недостаток. У Дельфи дизайнер не тормозит, но это же не заставлят меня говорить глупости

А книжку я купил два года назад. Она уже неактуальна

Здравствуйте, adontz, Вы писали:

A>По моей логике получается, что случаи бывают разные и не надо кричать "А-а-а-а, все учите WPF, лучше консоль, чем WinForms!", это не адекватно. Есть большие сектора разработки ПО в которых красота интерфейса далеко не на первом месте. Я своими глазами видел Dynamics NAV и меня от него тошнит. Я своими глазами видел 1С, в базовой конфигурации терпимо, но после переделок франчиз он может быть просто ужасен. За них платят миллионы. Я делаю выводы о важности красивого интерфейса для некоторых весьма платежеспособных категорий заказчиков. Байндинг из коробки в WPF лучше, всякие MVVM прикрутить проще. Вопрос только в том, чтобы не зацикливаться на технологиях. У меня сейчас есть программа просто сказка. WinForms, да, но один из лучших экземпляров. Красивый интерфейс, оптимизирован под разботу с клавиатурой, на трёх языках, везде автодополнение, цветовая индикация. Всё гармонично, качественный дизайн. А у клиента стоит программа на одном языке (причём не государственном), с существенно меньшим функционалом и... в ней нет двух кнопок одинакового размера, нет двух полей одинакового размера. Окна программы это хаотичные нагромождения элементов управления. Но старая программа им нравится! И я свою лапочку переделываю в говно, потому что они так привыкли. Вот эта жопа и есть реалии бизнеса. Интересует меня в такой ситуации крутой бандинг в WPF? Ничуть.
С такой позицией я могу согласиться. Если бы ты еще удержался от стебя над "крутым байндингом", был бы совсем респект.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>У нас видимо разные "действительности". Веб + ajaj + json + http compression, и меньше передавать уже вряд ли получится. Около килобайта на раундтрип при очень data-intensive приложении. Еще и клиентское кеширование есть.
A>Если тебе интересно, я могу попытаться посчитать трафик одной терминальной сессии с активно используемой ERP.
Ну это надо сравнить с объемом данных для веба.

A>>>К тому же отпадает вопрос о постраничном выводе как таковой.
G>>Не отпадает потому что постраничный нужен в первую очередь для человека.
A>Нет нужды в постраничной загрузке и нет нужды в постраничном выводе. При поиске картинок в Гугле постраничного вывода нет. Когда-нибудь постраничный вывод умрёт. Он не нужен людям, он нужет был исключительно для минимизации трафика во времена когда нельзя было подгружать без перезагрузки страницы.
Это чисто визуальный трюк, который по сути делает тот же постраничный вывод.

A>>>С терминалом можно (правда плохо, но можно) работать даже через GPRS.
G>>Очень плохо, но можно — считай нельзя.
A>Про очень никто не говорил. Подтормаживать иногда будет, но работать вполне возможно. Разница заметна, но не катастрофична.
Я вот с sharepoint много работаю. Открываю со своего ноута сайт — нормально работает, при этом remote desktop на ту же машину довольно ощутимо тормозит.
Весь прикол в том что remote desktop имеет латентность на каждое действие, а веб — только на отправку данных.

A>>>По сравнению с чем? Ты утверждаешь что веб (HTML или Silverlight) лучше WinForms или WPF.
G>>Угу, потому что работает на любой оси и на мобильных устройствах.

A>Ой, ну это просто сказки. Под Windows Силверлайт четвёртый, под MacOS третий,
Ты неправду говоришь.
http://go.microsoft.com/fwlink/?LinkID=188040 — Silverlight 4 для макоси
http://go.microsoft.com/fwlink/?LinkId=213905 — Silverlight 5 для макоси

A>под Linux какой-то Мунлайт, который непонятно чему соответствует
Это очень легко проверить: запустил, посмотрел где отвалилось, посмотрел в инете как поправить чтобы работало и так несколько раз.
Примерно на уровне SL3 сейчас.

A>под Android и iOS Силверлайта нет.
И не надо, SL то нужен для печати и все. Нафиг не надо с телефона печатать...

В итоге: без напряга получаем полный функционал для Windows, MacOs. Ограниченный под *nix и мобильные устройства.
Если постараться, то и под Linux помжно получить полный функционал.

A>При этом даже четвёртый так убог, что ты советуешь учить пятый.
Я советую учить пятый потому что к моменту когда человек что-то изучит пятый уже зарелизится.
Какой смысл изучать предыдущие версии?

A>>>Разница между Silverlight и WPF не заметна в микроскоп.
G>>Ты видимо очень много на SL писал что так утверждаешь.
A>Я правильно ттебя понял, что на Силверлайте писать удобнее, чем на WPF? Если я и ошибаюсь, то явно не в пользу твоих уверждений.
Нет, я утверждаю что разница между ними есть, это ты выдумал утверждение до "писать на sl удобнее, чем на wpf".

A>>>Веб-браузер не даст тебе свободы в UI. Даже клавиатурное сокращение толком назначить нельзя.
G>>Перехватывай нажатие клавиш и обрабатывай, в чем проблема?

A>В том что, например, Ctrl+D в файрфоксе создаёт закладку и хоть ты и можешь получить сообщение о том что Ctrl+D нажата, отменить действие по умолчанию ты не можешь. Когда я последний раз смотрел в оОпере было тоже самое. А сколько у нас ещё разных юраузеров разных версий? Везде свободных клавиатурных сочетаний крайне мало.
Дык не используй Ctrl+D. В чем проблема?
Тебе десятка сочетаний хватит? Я думаю везде найдется.
Больше наверное и запомнить сложно.

A>>>Silverlight или продвинутый движок HTML тоже.

G>>Да ну? HTML4 доступен чуть менее чем везде, HTML 5 доступен на любом десктопе. А что насчет remote desktop?

A>Вот как раз Remote Desktop действительно везде доступен. Все версии Windows, все версии Windows Mobile, Windows Phone 7, MacOS, Linux.
Этот софт надо ставить.

A>Причём пользователь получит абсолютно одинаковый UX и не надо думать об особенностях ОС на которйо он сидит.
Что-то я соменваюсь что пользователи обрадуются увидев "абсолютно одинаковый UX" на телефоне.

A>По факту RDP доступен на большем количестве платформе, чем Silverlight.
Что-то я пока не увидел "больше", не забывай что для веба sl использоваться будет только для расширения возможностей браузера.

A>>>Это неправда. Ставишь второй терминал, настраиваешь NLB, забываешь о проблеме. Я работал с фермами терминалов, никакой проблемы масштабирования там нет.
G>>Это на словах просто, а на деле не каждый админ потянет. По сравнению с масштабированием веб-решений на порядок сложнее.
A>Ой, ну что за глупости. Любая подобная балансировка нагрущзки под Windows делается через NLB, будет это 80й порт или 3389 порт, значения не имеет. Тот кто сделает одно, сделает и другое.
Ну тоже неверно, гугли webfarmframework.

A>>>Тоже не правда. Наоборот, в среде развитого домена Active Directory тебе вообще не надо что-либо настраивать, потому что все пользователи уже есть, уже объединены в группы и т.д.
G>>Я не про AD, его можно и в вебе использовать, я про разрешения на сервере терминалов и в приложении.
A>На сервер терминалов никаких особых разрешений задачать не надо, разве что сразу на всех через групповые политики. Разрешения в приложении вообще не зависят от способа подключения.
Ну как-бы реальный пример: одна говнопрограмма, запускающаяся под rdp требовала очень высоких прав для работы (типа писать в HKLM) хотела. Админы не подумали и дали права админа на сервере. В итоге кто-то повалил весь сервак имея эти самые права.
После этого админы еще долго мучались вылизывая разрешения чтобы и прога работала и свалить что-то нельзя было.
Слой абстракции в виде веба полностью решает проблемы.

A>>>Сколько стоит программист у которого хватит навыков? Сколько стоят два таких программиста (один мало, риски)? Зачем платить больше?
G>>Ну программисты на вебе, как ни странно, стоят дешевле админов, умеющих NLB поднимать.
A>Ты заблуждаешься. NLB поднять — пятиминутное дело.
Я поднимал, а также видел админов, которые не могли. Админов, которые могли, кстати получилось сильно меньше, чем веб-програмистов.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>>>DataTrigger-ы, команды, multibinding, FlowDocument, {DynamicResource}, биндинг к xpath, объединение ресурсов, наследование стилей — это только то, что я с ходу вспомнил; если покопаться — наберу раза в 2 больше. Большей части нет в SL4 и даже в 5. Ну и нафига?
G>>1)Большинство нафиг не нужно
S>Тут не КСВ и "___ не нужен" — ни разу не довод. Плиз, давайте будем обосновывать своё мнение

обоснование: sl и без этого прекрасно работает, причем уже пятую версию клепают. То что реально нужно — включают в sl. Команды сделали, Implicit Templates сделали

G>>2)SL это не только веб, но и windows phone
S>Угумс. Проблема в том, что мне периодически стучится в аську товарищ, занимаюшийся разработкой под WP7.
S>С самыми элементарными вопросами — как выровнять текст по ширине, как использовать compiled-регэксы, как захостить flow document, как показать gif, как прибиндиться с {RelativeSource AncestorType}, как поставить биндинг в стиле, как менять картинку в зависимости от значения нескольких свойств, как динамически менять оформление...

S>Я тоже должен был отвечать — оно всё не нужно?

FlowDocument и динамически менять оформление в wp7? А человек точно понимает что он делает?
Я же говорю — большая часть нафиг не нужна. Этим просто не надо заниматься.

Здравствуйте, gandjustas, Вы писали:

G>Весь прикол в том что remote desktop имеет латентность на каждое действие, а веб — только на отправку данных.

Согласен. Но на практике это не создаёт заметных проблем.

A>>Ой, ну это просто сказки. Под Windows Силверлайт четвёртый, под MacOS третий,
G>Ты неправду говоришь.
G>http://go.microsoft.com/fwlink/?LinkID=188040 — Silverlight 4 для макоси
G>http://go.microsoft.com/fwlink/?LinkId=213905 — Silverlight 5 для макоси

ХЗ, на сайте Эпла я 4 и 5 не нашёл.

A>>под Android и iOS Силверлайта нет.
G>И не надо, SL то нужен для печати и все. Нафиг не надо с телефона печатать...

Ты глубоко не прав. Я знаю с десяток компаний которые печатают с телефонов (или устройств аналогичных характеристик) на матричные принтеры через блютуз адаптер.

G>Дык не используй Ctrl+D. В чем проблема?
G>Тебе десятка сочетаний хватит? Я думаю везде найдется.
G>Больше наверное и запомнить сложно.

Ctrl+Alt+Shift+F7 свободно может и везде, но толку от этого никакого. Есть общепринятые сочетания клавиш, есть сочетания клавиш, которые были в какой-то другой, знакомой, программе и т.д.

A>>Вот как раз Remote Desktop действительно везде доступен. Все версии Windows, все версии Windows Mobile, Windows Phone 7, MacOS, Linux.
G>Этот софт надо ставить.

А Силверлайт не надо?

Кстати под Windows ставить RDP не надо.

A>>По факту RDP доступен на большем количестве платформе, чем Silverlight.
G>Что-то я пока не увидел "больше", не забывай что для веба sl использоваться будет только для расширения возможностей браузера.

Ну сравни списки и увидишь.

A>>Ой, ну что за глупости. Любая подобная балансировка нагрузки под Windows делается через NLB, будет это 80й порт или 3389 порт, значения не имеет. Тот кто сделает одно, сделает и другое.
G>Ну тоже неверно, гугли webfarmframework.

Это вообще другого уровня решение. NLB компонент ОС администрирование которого входит в програмы базовой сертификации.

A>>На сервер терминалов никаких особых разрешений задачать не надо, разве что сразу на всех через групповые политики. Разрешения в приложении вообще не зависят от способа подключения.
G>Ну как-бы реальный пример: одна говнопрограмма, запускающаяся под rdp требовала очень высоких прав для работы (типа писать в HKLM) хотела. Админы не подумали и дали права админа на сервере. В итоге кто-то повалил весь сервак имея эти самые права.

Это крайне редкая проблема + неправильное её решение.

G>После этого админы еще долго мучались вылизывая разрешения чтобы и прога работала и свалить что-то нельзя было.
G>Слой абстракции в виде веба полностью решает проблемы.

Связь между странной попыткой записи в HKLM и вебом чуть менее чем никакая.

A>>Ты заблуждаешься. NLB поднять — пятиминутное дело.
G>Я поднимал, а также видел админов, которые не могли. Админов, которые могли, кстати получилось сильно меньше, чем веб-програмистов.

Таких "админов", которые не умеют администрировать базовые компоненты ОС, надо гнать. Я видел "админа", который не знал что такое DNS. Я же не стал после этого везде использовать IP адреса

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

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Весь прикол в том что remote desktop имеет латентность на каждое действие, а веб — только на отправку данных.
A>Согласен. Но на практике это не создаёт заметных проблем.
Угу, наверное поэтому на вебе делается на порядок больше, чем с использование remote desktop. Просто ты привык и проблем не замечаешь, хотя многое можно было бы сделать проще.

A>>>под Android и iOS Силверлайта нет.
G>>И не надо, SL то нужен для печати и все. Нафиг не надо с телефона печатать...
A>Ты глубоко не прав. Я знаю с десяток компаний которые печатают с телефонов (или устройств аналогичных характеристик) на матричные принтеры через блютуз адаптер.
А смысл мобильные устройства на то и мобильные чтобы их можно было носить с собой везде. В поезде или машине например, принтер такими свойствами не обладает. 0.00001% юзкейсов даже рассматривать не хочу.

G>>Дык не используй Ctrl+D. В чем проблема?
G>>Тебе десятка сочетаний хватит? Я думаю везде найдется.
G>>Больше наверное и запомнить сложно.

A>Ctrl+Alt+Shift+F7 свободно может и везде, но толку от этого никакого. Есть общепринятые сочетания клавиш, есть сочетания клавиш, которые были в какой-то другой, знакомой, программе и т.д.
Самые частоиспользуемые и так работают, они завязаны на редактирование текста.

A>>>Вот как раз Remote Desktop действительно везде доступен. Все версии Windows, все версии Windows Mobile, Windows Phone 7, MacOS, Linux.
G>>Этот софт надо ставить.

A>А Силверлайт не надо?

Если Windows Update включен, то не надо, страница сама предлагает, administrative effort нулевой.

A>>>Ой, ну что за глупости. Любая подобная балансировка нагрузки под Windows делается через NLB, будет это 80й порт или 3389 порт, значения не имеет. Тот кто сделает одно, сделает и другое.
G>>Ну тоже неверно, гугли webfarmframework.
A>Это вообще другого уровня решение. NLB компонент ОС администрирование которого входит в програмы базовой сертификации.
Угу, я на одного сертифицированного вижу 10 абсолютно безграмотных админов. Ситуация со временем не меняется.

A>>>На сервер терминалов никаких особых разрешений задачать не надо, разве что сразу на всех через групповые политики. Разрешения в приложении вообще не зависят от способа подключения.
G>>Ну как-бы реальный пример: одна говнопрограмма, запускающаяся под rdp требовала очень высоких прав для работы (типа писать в HKLM) хотела. Админы не подумали и дали права админа на сервере. В итоге кто-то повалил весь сервак имея эти самые права.

A>Это крайне редкая проблема + неправильное её решение.
Это как раз крайне частая проблема. Куча десктопного кастомного софта требуют права админа.
Правильное решение проблемы это затраты, которые заранее никто не планировал.

G>>После этого админы еще долго мучались вылизывая разрешения чтобы и прога работала и свалить что-то нельзя было.
G>>Слой абстракции в виде веба полностью решает проблемы.

A>Связь между странной попыткой записи в HKLM и вебом чуть менее чем никакая.
Для веба сильно другой инструментарий используется, другие привычки и гайдлайны. 99,9% веб-разработчиков и не подумают в реестр писать, а куча десктопных программ, требующие права админа — факт.

Здравствуйте, gandjustas, Вы писали:

G>>>Весь прикол в том что remote desktop имеет латентность на каждое действие, а веб — только на отправку данных.
A>>Согласен. Но на практике это не создаёт заметных проблем.
G>Угу, наверное поэтому на вебе делается на порядок больше, чем с использование remote desktop. Просто ты привык и проблем не замечаешь, хотя многое можно было бы сделать проще.

Оба утверждения странные. Приложение не делается для терминала как-то особенно, поэтому как ты сравнил количество бизнес-приложений на вебе и в терминале я не понимаю. И я не использую терминал сам, поэтому я не мог к чему-либо привыкнуть. Я пишу приложения, которые время-от времени используют и в терминале тоже, но я их пишу так, что мне не надо их переписывать. Иногда о том что приложения используется в терминале я узнаю чуть-ли не последним.

A>>Ты глубоко не прав. Я знаю с десяток компаний которые печатают с телефонов (или устройств аналогичных характеристик) на матричные принтеры через блютуз адаптер.
G>А смысл мобильные устройства на то и мобильные чтобы их можно было носить с собой везде. В поезде или машине например, принтер такими свойствами не обладает. 0.00001% юзкейсов даже рассматривать не хочу.

Ну вот ты не разбираешься в предметной области, а опять навешиваешь ярлыки. Принтер в машине, это мобильные сотрудники, которые ездят на служебных машинах. Так работают абсолютно все дистрибьюторские компании с которыми я общался: еда, билеты, стиральные порошки.

A>>Ctrl+Alt+Shift+F7 свободно может и везде, но толку от этого никакого. Есть общепринятые сочетания клавиш, есть сочетания клавиш, которые были в какой-то другой, знакомой, программе и т.д.
G>Самые частоиспользуемые и так работают, они завязаны на редактирование текста.

Ты заблуждаешься.

A>>А Силверлайт не надо?

G>Если Windows Update включен, то не надо, страница сама предлагает, administrative effort нулевой.

А RDP есть и без WU.

A>>Это крайне редкая проблема + неправильное её решение.
G>Это как раз крайне частая проблема. Куча десктопного кастомного софта требуют права админа.
G>Правильное решение проблемы это затраты, которые заранее никто не планировал.

Я не знаю откуда ты взял эту кучу. Я уже очень давно с таким не сталкивался.

A>>Связь между странной попыткой записи в HKLM и вебом чуть менее чем никакая.
G>Для веба сильно другой инструментарий используется, другие привычки и гайдлайны. 99,9% веб-разработчиков и не подумают в реестр писать, а куча десктопных программ, требующие права админа — факт.

Зато они запросто подумают что база должна быть MDB, потому что на халявном хостинге, на котором лежит демо, нет MSSQL и лежать она должна в папке C:\Inetpub\ потому что этот путь зашит в программе. Накосячить можно везде. Терминал это ещё и SSO, а вот как твоё веб-приложение пройдёт аудит безопасности вопрос отдельный.

Сабж тоже интересует, т.к. ни одном ни в другом я не копенгаген, но надо прибиваться какому-то берегу. Прежде всего интересуют обычные Windows GUI программы, можно сказать так называемые толстые клиенты, т.е. то, что когда-то делалось на MFC или "голом" Win32 API (QT не предлагать). Свистелки и перделки типа воспроизведения аудио/видео интересуют в последнюю очередь и то если их можно просто добавить. Предположим, надо разработать отображение табличных данных по типу Excel. Будет ли достаточно winform для подобных приложений? Kак я понял из обсуждения, WPF это очень круто, но очень долго в смысле обучения, а winform это просто, но уже старо, что-ли. Так?

Здравствуйте, Аноним, Вы писали:

А>Предположим, надо разработать отображение табличных данных по типу Excel.

Что WinForms, что WPF, что ASP.Net вам проще (заметно) купить сторонний компонент, если функциолнальности DataGridView существенно не хватает.

A>Что WinForms, что WPF, что ASP.Net вам проще (заметно) купить сторонний компонент, если функциолнальности DataGridView существенно не хватает.
Согласен. Хорошо, покупаем компонент. Но надо же его куда-то встроить, т.е. надо сначала изучить либо WinForms либо WPF.

Здравствуйте, Аноним, Вы писали:

A>>Что WinForms, что WPF, что ASP.Net вам проще (заметно) купить сторонний компонент, если функциолнальности DataGridView существенно не хватает.
А>Согласен. Хорошо, покупаем компонент. Но надо же его куда-то встроить, т.е. надо сначала изучить либо WinForms либо WPF.

WinForms изучить проще. Думаю с этим никто не будет спорить. Библиотека практически не развивается самим Microsoft (хотя в 4 фремворке исправили несколько багов, так что...), но есть огромное количество (не потому что WPF хуже, а просто потому что WinForms значительно дольше существует) сторонних компонент. В том числе беплатных. Бесплатных компонент для WPF тоже не мало. В любом случае даже у платных качество бывает так себе, так что тут надо под конкретную задачу искать.

Если говорить именно про элемент управления максимально похожий на Excel, то для WPF я вообще ничего не встречал. Для WinForms есть spreadsheetgear, но он считает высоту строк не так как Excel. То есть в Excel при печати на листе помещается 20 строк, а в SSG — 19 строк.

Если нужен просто грид, то такого добра предостаточно для всех библиотек.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>>>Весь прикол в том что remote desktop имеет латентность на каждое действие, а веб — только на отправку данных.
A>>>Согласен. Но на практике это не создаёт заметных проблем.
G>>Угу, наверное поэтому на вебе делается на порядок больше, чем с использование remote desktop. Просто ты привык и проблем не замечаешь, хотя многое можно было бы сделать проще.

A>Оба утверждения странные. Приложение не делается для терминала как-то особенно, поэтому как ты сравнил количество бизнес-приложений на вебе и в терминале я не понимаю. И я не использую терминал сам, поэтому я не мог к чему-либо привыкнуть. Я пишу приложения, которые время-от времени используют и в терминале тоже, но я их пишу так, что мне не надо их переписывать. Иногда о том что приложения используется в терминале я узнаю чуть-ли не последним.

Любое приложение не пишется как-то особенно. Только веб изначально доставляет меньше проблем, которые пытаются решить терминальным доступом.
Иначе не был бы веб сейчас так популярен.

A>>>Ты глубоко не прав. Я знаю с десяток компаний которые печатают с телефонов (или устройств аналогичных характеристик) на матричные принтеры через блютуз адаптер.
G>>А смысл мобильные устройства на то и мобильные чтобы их можно было носить с собой везде. В поезде или машине например, принтер такими свойствами не обладает. 0.00001% юзкейсов даже рассматривать не хочу.

A>Ну вот ты не разбираешься в предметной области, а опять навешиваешь ярлыки. Принтер в машине, это мобильные сотрудники, которые ездят на служебных машинах. Так работают абсолютно все дистрибьюторские компании с которыми я общался: еда, билеты, стиральные порошки.
Да, да, помню я. Это как раз решается созданием специализированной клиентской версии, заточенной под свои задачи.

Еще раз: большая часть кейсов покрывается веб-приложением на html\css\js. Там где не хватает пишется отдельное предложение со специализированным интерфейсом. Это и полезнее с точки зрения реализации кейсов.

Например в macdonalds есть кассы со своим интерфейсом, есть мобильные терминалы и переносной принтер. Странно что они удаленный рабочий стол не догадались использовать

A>>>Ctrl+Alt+Shift+F7 свободно может и везде, но толку от этого никакого. Есть общепринятые сочетания клавиш, есть сочетания клавиш, которые были в какой-то другой, знакомой, программе и т.д.
G>>Самые частоиспользуемые и так работают, они завязаны на редактирование текста.
A>Ты заблуждаешься.
Ctrl+Z, Ctrl+X, Ctrl+C, Ctrl+V, Ctrl+B, Ctrl+I все работает, больше я и не знаю.

A>>>А Силверлайт не надо?

G>>Если Windows Update включен, то не надо, страница сама предлагает, administrative effort нулевой.

A>А RDP есть и без WU.
Ага, особенно на линуксе и маке

A>>>Это крайне редкая проблема + неправильное её решение.
G>>Это как раз крайне частая проблема. Куча десктопного кастомного софта требуют права админа.
G>>Правильное решение проблемы это затраты, которые заранее никто не планировал.
A>Я не знаю откуда ты взял эту кучу. Я уже очень давно с таким не сталкивался.
Ты вообще в каком-то идеальном мире живешь. У тебя устаревших приложений нет, зато встречаются кейсы, которые у других встречаются один на миллион.

A>>>Связь между странной попыткой записи в HKLM и вебом чуть менее чем никакая.
G>>Для веба сильно другой инструментарий используется, другие привычки и гайдлайны. 99,9% веб-разработчиков и не подумают в реестр писать, а куча десктопных программ, требующие права админа — факт.

A>Зато они запросто подумают что база должна быть MDB, потому что на халявном хостинге, на котором лежит демо, нет MSSQL и лежать она должна в папке C:\Inetpub\ потому что этот путь зашит в программе.
Ты таких заешь? Я — нет.

A>Накосячить можно везде.
Можно, но где-то больше возможностей, где-то меньше. Для веба меньше, обычно веб приложения на более высоком уровне абстракции работают.

A>Терминал это ещё и SSO, а вот как твоё веб-приложение пройдёт аудит безопасности вопрос отдельный.
А что мешает в вебе SSO сделать?

ЗЫ. Вообще многие твои советы, которые ты даешь в этой теме, адекватны только с учетом кучи редких кейсов, которые кажись только у тебя и встречаются.

Спасибо за ответ, значит WinForms все еще котируется для подобных приложений, и даже по видимому наиболее оптимальное решение с точки зрения времени разработки (для чайника). Какая студия минимально подойдет для этого? 2005, 2008 или обязательно 2010?
В принципе, похожесть на Excel совсем не важна, т.е. надо обычный, но достаточно красивый, грид, ячейки которого можно редактировать; где каждая ячейка, строка, или колонка может отображается в заданнном формате/цвете. Еще хорошо бы иметь несколько страниц таблиц (как в Excelе) и возможность брать и сохранять данные из файла, базы данных, или из сокета.

Здравствуйте, Аноним, Вы писали:

А>Спасибо за ответ, значит WinForms все еще котируется для подобных приложений, и даже по видимому наиболее оптимальное решение с точки зрения времени разработки (для чайника). Какая студия минимально подойдет для этого? 2005, 2008 или обязательно 2010?
А>В принципе, похожесть на Excel совсем не важна, т.е. надо обычный, но достаточно красивый, грид, ячейки которого можно редактировать; где каждая ячейка, строка, или колонка может отображается в заданнном формате/цвете. Еще хорошо бы иметь несколько страниц таблиц (как в Excelе) и возможность брать и сохранять данные из файла, базы данных, или из сокета.

А почему бы не взять excel + vsto?

Здравствуйте, Аноним, Вы писали:

А>Спасибо за ответ, значит WinForms все еще котируется для подобных приложений, и даже по видимому наиболее оптимальное решение с точки зрения времени разработки (для чайника). Какая студия минимально подойдет для этого? 2005, 2008 или обязательно 2010?

Любая.

А>В принципе, похожесть на Excel совсем не важна, т.е. надо обычный, но достаточно красивый, грид, ячейки которого можно редактировать; где каждая ячейка, строка, или колонка может отображается в заданнном формате/цвете. Еще хорошо бы иметь несколько страниц таблиц (как в Excelе) и возможность брать и сохранять данные из файла, базы данных, или из сокета.

Если особых требований нет, стандартного DataGridView вполне хватит. Страницы можно сделать табом.

Здравствуйте, gandjustas, Вы писали:

G>А почему бы не взять excel + vsto?

Excel не бесплатен.

Здравствуйте, gandjustas, Вы писали:

G>Любое приложение не пишется как-то особенно. Только веб изначально доставляет меньше проблем, которые пытаются решить терминальным доступом.
G>Иначе не был бы веб сейчас так популярен.

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

G>Да, да, помню я. Это как раз решается созданием специализированной клиентской версии, заточенной под свои задачи.

Но не вебом

G>Например в macdonalds есть кассы со своим интерфейсом, есть мобильные терминалы и переносной принтер. Странно что они удаленный рабочий стол не догадались использовать

Во-первых, я не говорил что терминал решит все проблемы. Я вообще за него не агитировал, я лишь сказал что есть компании в которых используют терминальные сессии и есть объективные причины почему так стоит делать. Переводить всех на веб в общем случае не приемлемое решение.
во-вторых, веба к макдональдсе тоже нет, так что что ты пытался доказать не понятно.

A>>Ты заблуждаешься.
G>Ctrl+Z, Ctrl+X, Ctrl+C, Ctrl+V, Ctrl+B, Ctrl+I все работает, больше я и не знаю.

Уверен, ты знаешь F5

A>>А RDP есть и без WU.
G>Ага, особенно на линуксе и маке

А в Линуксе или на маке есть Силверлайт через из коробки? Мне эта подтема надоела. Утверждать что силверлайт доступнее RDP просто нелепо.

A>>Я не знаю откуда ты взял эту кучу. Я уже очень давно с таким не сталкивался.
G>Ты вообще в каком-то идеальном мире живешь. У тебя устаревших приложений нет, зато встречаются кейсы, которые у других встречаются один на миллион.

Ой ну да, только твой кейсы самые популярные.

A>>Зато они запросто подумают что база должна быть MDB, потому что на халявном хостинге, на котором лежит демо, нет MSSQL и лежать она должна в папке C:\Inetpub\ потому что этот путь зашит в программе.
G>Ты таких заешь? Я — нет.

А я знаю лично. Правда мы этих людей перевоспитали.

A>>Накосячить можно везде.
G>Можно, но где-то больше возможностей, где-то меньше. Для веба меньше, обычно веб приложения на более высоком уровне абстракции работают.

Обычно, веб приложения двузвенки с говёной архитектурой без выделенного DAL (LINQ != DAL) и BLL. О каком тут можно говорить уровне абстракции?

A>>Терминал это ещё и SSO, а вот как твоё веб-приложение пройдёт аудит безопасности вопрос отдельный.
G>А что мешает в вебе SSO сделать?

NTLM через Интернет?

G>ЗЫ. Вообще многие твои советы, которые ты даешь в этой теме, адекватны только с учетом кучи редких кейсов, которые кажись только у тебя и встречаются.

Я могу тебе написать абсолютно тоже самое.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>А почему бы не взять excel + vsto?

A>Excel не бесплатен.

На порядок дешевле аналогичной разработки.

Здравствуйте, gandjustas, Вы писали:

A>>Excel не бесплатен.
G>На порядок дешевле аналогичной разработки.

ЭУ как правило royality free, а Excel стоит 100 баксов на рабочее место.

сам Excel на машине есть, но он скорее всего не подходит потому, что это наверное будет медленно. Надо "достаточно" быстро отображать изменяющиеся данные в разных ячейках.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Любое приложение не пишется как-то особенно. Только веб изначально доставляет меньше проблем, которые пытаются решить терминальным доступом.
G>>Иначе не был бы веб сейчас так популярен.
A>Популярность веба утверждение которое может быть и истиным и ложным, в зависимости от сегмента рынка.
Вопрос то был не про сегменты.

G>>Да, да, помню я. Это как раз решается созданием специализированной клиентской версии, заточенной под свои задачи.
A>Но не вебом

Это может быть и SL. В Windows Phone 7 кстати тоже SL, который мало отличается от того что в вебе. более того между ними можно и код шарить.

G>>Например в macdonalds есть кассы со своим интерфейсом, есть мобильные терминалы и переносной принтер. Странно что они удаленный рабочий стол не догадались использовать

A>Во-первых, я не говорил что терминал решит все проблемы. Я вообще за него не агитировал, я лишь сказал что есть компании в которых используют терминальные сессии и есть объективные причины почему так стоит делать. Переводить всех на веб в общем случае не приемлемое решение.

Опять ты неправду говоришь.
Твое первое сообщение в теме:

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

Немного не так звучит как ты сейчас говоришь.

A>во-вторых, веба к макдональдсе тоже нет, так что что ты пытался доказать не понятно.
Уверен? Я только два интерфейса видел. Готов посморить что внутри используются вебовые технологии.
Кстати можешь посмотреть DinnerNow.NET — пример аналогичного класса приложений.

A>>>Ты заблуждаешься.
G>>Ctrl+Z, Ctrl+X, Ctrl+C, Ctrl+V, Ctrl+B, Ctrl+I все работает, больше я и не знаю.
A>Уверен, ты знаешь F5

уверен что большинство пользователей f5 понимают как "обновить", в вебе оно так и будет работать

A>>>А RDP есть и без WU.
G>>Ага, особенно на линуксе и маке

A>А в Линуксе или на маке есть Силверлайт через из коробки? Мне эта подтема надоела. Утверждать что силверлайт доступнее RDP просто нелепо.
Еще раз: SL и Moonlight можно установить прямо со старницы.
Тем более SL не является обязательным для большинства кейсов, в отличие от rdp.
Ты как-то постоянно упускаешь из вида эти два фактора.

A>>>Я не знаю откуда ты взял эту кучу. Я уже очень давно с таким не сталкивался.
G>>Ты вообще в каком-то идеальном мире живешь. У тебя устаревших приложений нет, зато встречаются кейсы, которые у других встречаются один на миллион.
A>Ой ну да, только твой кейсы самые популярные.
Ну ты же видел картинку: http://files.rsdn.ru/34572/skills-chart.png
Спрос на веб в разы больше чем спрос на десктопные технологии.

A>>>Накосячить можно везде.
G>>Можно, но где-то больше возможностей, где-то меньше. Для веба меньше, обычно веб приложения на более высоком уровне абстракции работают.
A>Обычно, веб приложения двузвенки с говёной архитектурой без выделенного DAL (LINQ != DAL) и BLL. О каком тут можно говорить уровне абстракции?
Об уровне абстракции над ОС.

A>>>Терминал это ещё и SSO, а вот как твоё веб-приложение пройдёт аудит безопасности вопрос отдельный.
G>>А что мешает в вебе SSO сделать?
A>NTLM через Интернет?

Ну конечно нет, гугли WIF и ADFSv2.

G>>ЗЫ. Вообще многие твои советы, которые ты даешь в этой теме, адекватны только с учетом кучи редких кейсов, которые кажись только у тебя и встречаются.
A>Я могу тебе написать абсолютно тоже самое.
Вот только создается веб-приложений на порядок больше. Еще дядька фаулер, в далеком 2002 году писал что если нет причини не использовать веб, то надо именно веб-приложение создавать. Ну он наверное тоже рассматривал крайне редкие кейсы...

А ведь за 10 лет веб-технологии шагнули очень далеко вперед.

Здравствуйте, Аноним, Вы писали:

А>сам Excel на машине есть, но он скорее всего не подходит потому, что это наверное будет медленно. Надо "достаточно" быстро отображать изменяющиеся данные в разных ячейках.

"Достаточно" это сколько?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>сам Excel на машине есть, но он скорее всего не подходит потому, что это наверное будет медленно. Надо "достаточно" быстро отображать изменяющиеся данные в разных ячейках.

G>"Достаточно" это сколько?

Скажем за 100-200 ms надо обновить из программы данные в 100 ячейках

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Аноним, Вы писали:

А>>>сам Excel на машине есть, но он скорее всего не подходит потому, что это наверное будет медленно. Надо "достаточно" быстро отображать изменяющиеся данные в разных ячейках.

G>>"Достаточно" это сколько?

А>Скажем за 100-200 ms надо обновить из программы данные в 100 ячейках

Ну так проведи замеры. Мне кажется что excel+vsto отлично справятся.

Какая студия нужна для vsto? Я пытался использовать 2005, но не вышло. Не помню точно, то ли микрософт уже удалил vsto для 2005, то ли оно как-то встало не так, но я так и не смог создать там vsto проект.

Здравствуйте, Аноним, Вы писали:

А>Какая студия нужна для vsto? Я пытался использовать 2005, но не вышло. Не помню точно, то ли микрософт уже удалил vsto для 2005, то ли оно как-то встало не так, но я так и не смог создать там vsto проект.
Лучше всего использовать vs2010 и .NET4, так как много на com сделано и без dynamic сложно из C# будет работать.

evo>стоит ли учить winforms или сразу переходить к WPF.

Сейчас ситуация не совсем однозначная: с одной стороны, WinForms морально устарел, но он надёжен и прост как молоток: написана (и отлажена, в отличии от WPF) такая куча сторонних контролов, что маловероятно написание собственных велокнопок. Устарел в плане перспектив и новых выкрутасов, но сам по себе работает на ура, документирован вдоль и поперёк. Другими словами, если есть задача "написать что-то на ВыньФормс за месяц", она будет решена полностью и за месяц — это проверенный бизнесом процесс. Кроме того, WinForms базируется на Win32, которая сдавать позиции и не собирается (как бы мелкософт это не желала), так что аргументы а-ля "ВПФ лучше, потому что Win32 умрёт" — смехотворны.

А с другой строны (которую ошибочно принимают за лучшую

) стоит WPF. Ну, тут можно сразу по пунктам, чтобы калозакидатели метче попадали.

В своём современном виде эта технология просто зелёный сопляк, впервые понюхавший пороху — не обкатана ни в одном долгосрочном и сложном проекте. Ещё не набрана критическая масса use-case'ов, позволяющих однозначно сказать, что улучшать в ВПФ больше нечего. Обязательно будут вылезать проблемы с дизайном ВПФ, т.к. его едва успели сделать.
Порог вхождения в ВПФ — крутая синусоида: сначала всё кажется просто, а затем ты резко упираешься лбом в шаблоны, стили, команды, биндинги и вся эта куча нужна сразу, т.к. всё сцеплено в "умные шаблоны проектирования" (умные в теориях, конечно же). Пропустишь хоть одну технологию — приложение выйдет "кривозадизайненное", по поводу чего РСДНовцы тебя радостно макнут в Г. Я бы не назвал "умным" подобный подход.
Консультироваться тоже, увы, придётся у новоиспечённых "экспертов" (см. п.1). Люди годами намозоливали опыт ВыньФормс, т.к. не сразу тебе нужны все тонкости библиотеки. Совершенно аналогично с ВПФ — пока каждый набьёт шишек (раздавая попутно "почти правильные" советы), должно пройти время и это не жалкие 3 года ВПФа.
Хоть ВПФ и преподносится как "новое решение", совсем не факт, что это решение идеально. Хуже того — уже сейчас мне (уж простите за ИМХО) виден бредовый симбиоз "декларативности" и "кода" — два совершенно ортогональных явления, засунутых под маской XML. И чудес тут не будет: если кнопка должна сиять, хоть в атрибут это засунь, хоть в задницу, но код сияния должен быть кем-то написан! Т.е. декларативные конструкции не стоят и гроша, если за ними нет правильных верёвочек к правильным функциям. Только в коде это более прямолинейно и доступно, а вот с декларациями ты ещё попляшешь! Отсюда вытекает и следующий пункт...
Только самые тривиальные кастомизации в ВПФ обходятся парой атрибутов/стилей. Всё остальное вас приведёт к целым простыням шаблонов-триггеров-стилей-биндингов, заменяющих по сути тот же код, но через анус. Грубо говоря, представьте, что вам нужно C# представить в виде XML, причём теги должны быть названиями контролов! Это и есть ВПФ. Отсюда сразу же следует сложность поддержки монстроидальных шаблонов — немного найдётся даже "середнячков", способных разобраться в этих наворотах.
А пока поддержка не нужна, попробуй ОТЛАДИТЬ свои темплейтные каракули! ВыньФормсный код — с ним что, прыг-прыг по функциям, брэкпойнтов наставил — баг раздавлен. А теперь пусть аналогично удобную отладку нам продемонстрируют апологеты ВПФ!
Как уже не раз отмечалось (и видно даже невооружённым взглядом), формы на ВПФ работают тормознутее WinForms. Я не знаю, ГДЕ мелкософт применила DirectX, но сей парадокс уже тянет на глобальное враньё или полный провал архитектуры: ускоряющая библиотека — есть, а ускорения — нет! И вобщем-то, даже не важно, почему — важно то, что "а вот такое же, но на винформс не тормозило!". И деньги уйдут от "трёхбуквенных теоретиков MVC" к простым мастерам вынформса.
У ВПФ есть некоторые правильные идеи, но идеи, не будучи правильно и органично вплетёнными в общую конструкцию, теряют весь потенциал. Не вижу резона размахивать "динамическим" ВПФ, если я даже дизайн формы не могу сменить одной строкой кода! Не стоит и гроша "декларативная кнопка", если для неё я пишу "деклараций" в три раза больше сишарпного кода. Нет бенефита от биндингов, если я вынужден руками писать тонны DependencyProperties. Не размахивайте зазубренными идеями, "just show me the code".

Так что ВПФ "новее" только хронологически, его будут пропихивать вперёд, обвешивать плюшками, но то, что с ним вы быстро решите свои бизнес-задачи — далеко не факт.
А если ещё всякие Qt/GTk набегут, вообще цирк будет. Вот и решайте....

Здравствуйте, gandjustas, Вы писали:

G>обоснование: sl и без этого прекрасно работает, причем уже пятую версию клепают. То что реально нужно — включают в sl. Команды сделали, Implicit Templates сделали

Проблема в том, что такими темпами до нормального WPF сильверлайту телепаться ещё релиза 2-3. За это время большая часть написанного кода обрастёт такими костылями, что наличие/отстутствие фич в SL не будет играть никакой роли. МС снова и снова наступают на одни и те же грабли — выкатывают сырой продукт, а затем поддерживают с ним совместимость.

G>FlowDocument и динамически менять оформление в wp7? А человек точно понимает что он делает?
Иногда под WP7 пишут не только развлекательный софт, но и бизнес-приложения. И там таки нужен интерактивный текст с форматированием и динамическое изменение раскладки/внешнего вида. Второе ещё обходится навигацией на новую страницу, первое — увы.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>обоснование: sl и без этого прекрасно работает, причем уже пятую версию клепают. То что реально нужно — включают в sl. Команды сделали, Implicit Templates сделали

S>Проблема в том, что такими темпами до нормального WPF сильверлайту телепаться ещё релиза 2-3.
Учитывая темп релизов это примерно год

S>За это время большая часть написанного кода обрастёт такими костылями, что наличие/отстутствие фич в SL не будет играть никакой роли.
Не понял логики.

S>МС снова и снова наступают на одни и те же грабли — выкатывают сырой продукт, а затем поддерживают с ним совместимость.
Это не грабли. Я не готов сидеть и ждать идеального мегапродукта годами.

G>>FlowDocument и динамически менять оформление в wp7? А человек точно понимает что он делает?
S>Иногда под WP7 пишут не только развлекательный софт, но и бизнес-приложения. И там таки нужен интерактивный текст с форматированием и динамическое изменение раскладки/внешнего вида. Второе ещё обходится навигацией на новую страницу, первое — увы.
Гайдлайны прочитай. Не нужно там это.

Здравствуйте, gandjustas, Вы писали:

G>Немного не так звучит как ты сейчас говоришь.

Немного не так звучит, потому что немного не про то говорили. Речь про Desktop vs. Web, а не RDP vs. Web.

A>>Уверен, ты знаешь F5

G>уверен что большинство пользователей f5 понимают как "обновить", в вебе оно так и будет работать

Да, перезагрузит всю страницу, а надо было только элементе в списке имеющем фокус. А если список не в фокусе, то вообще ничего не делать.

G>Еще раз: SL и Moonlight можно установить прямо со старницы.
G>Тем более SL не является обязательным для большинства кейсов, в отличие от rdp.
G>Ты как-то постоянно упускаешь из вида эти два фактора.

Операционная система	Remote Desktop	Silverlight
Windows XP, Vista, Seven	Встроен	Устанавливается
Windows Mobile	Встроен	Не доступен
Windows Phone 7	Устанавливается	Встроен
MacOS	Устанавливается	Устанавливается
iOS	Устанавливается	Не доступен
Linux	Устанавливается	Устанавливается
Android	Устанавливается	Не доступен

Для тех кто не ходит в четвёртый класс, напоминаю что семь больше четырёх. Миф о Силверлайте более доступном, чем RDP развенчан.

G>Ну ты же видел картинку: http://files.rsdn.ru/34572/skills-chart.png
G>Спрос на веб в разы больше чем спрос на десктопные технологии.

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

G>Вот только создается веб-приложений на порядок больше. Еще дядька фаулер, в далеком 2002 году писал что если нет причини не использовать веб, то надо именно веб-приложение создавать. Ну он наверное тоже рассматривал крайне редкие кейсы...

G>А ведь за 10 лет веб-технологии шагнули очень далеко вперед.

gandjustas, ни в споре со мной, ни в споре с Sinix ты не привёл ни одного сколько-нибудь стоящего аргумента, а теперь ещё и сослался на авторитет. Ты скучен.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Уверен, ты знаешь F5

G>>уверен что большинство пользователей f5 понимают как "обновить", в вебе оно так и будет работать

A>Да, перезагрузит всю страницу, а надо было только элементе в списке имеющем фокус. А если список не в фокусе, то вообще ничего не делать.
Для подавляющего большинства пользователей f5 — перегрузить всю страницу.

G>>Еще раз: SL и Moonlight можно установить прямо со старницы.
G>>Тем более SL не является обязательным для большинства кейсов, в отличие от rdp.
G>>Ты как-то постоянно упускаешь из вида эти два фактора.

A>
A>
A>
A>
A>
A>
A>
A>
A>
A>

Операционная система	Remote Desktop	Silverlight
Windows XP, Vista, Seven	Встроен	Устанавливается
Windows Mobile	Встроен	Не доступен
Windows Phone 7	Устанавливается	Встроен
MacOS	Устанавливается	Устанавливается
iOS	Устанавливается	Не доступен
Linux	Устанавливается	Устанавливается
Android	Устанавливается	Не доступен

A>Для тех кто не ходит в четвёртый класс, напоминаю что семь больше четырёх. Миф о Силверлайте более доступном, чем RDP развенчан.
Во-первых ты сам придумал этот миф. Я тебе говорил о большей доступности веба, а не конкретно SL.
Во-вторых смотри второй фактор. SL необязателен для работы так что пририсуй четвертую колонку где укажи необходимость применения. Там где его нет он и не нужен.

G>>Ну ты же видел картинку: http://files.rsdn.ru/34572/skills-chart.png
G>>Спрос на веб в разы больше чем спрос на десктопные технологии.
A>Мы гвоорим про безнес-приложения, а на вебе могут быть просто сайты. Эта картинка не означает вообще ничего.
А чем "просто сайты" принципиально отличаются от "бизнес приложений"? Там код какой-то другой?

G>>Вот только создается веб-приложений на порядок больше. Еще дядька фаулер, в далеком 2002 году писал что если нет причини не использовать веб, то надо именно веб-приложение создавать. Ну он наверное тоже рассматривал крайне редкие кейсы...

G>>А ведь за 10 лет веб-технологии шагнули очень далеко вперед.

A>gandjustas, ни в споре со мной, ни в споре с Sinix ты не привёл ни одного сколько-нибудь стоящего аргумента, а теперь ещё и сослался на авторитет. Ты скучен.
Я тебе привел аргументы, но ты их не увидел. Я тебе рассказал про гораздо более хорошее масштабирование и управляемость, про снижение трафика итп
Причем это факты. Если у тебя иногда получается как-то подругому, то это только у тебя и только иногда.

Здравствуйте, gandjustas, Вы писали:

G>>>уверен что большинство пользователей f5 понимают как "обновить", в вебе оно так и будет работать

A>>Да, перезагрузит всю страницу, а надо было только элементе в списке имеющем фокус. А если список не в фокусе, то вообще ничего не делать.
G>Для подавляющего большинства пользователей f5 — перегрузить всю страницу.

Это просто ограничение веба.

G>Во-вторых смотри второй фактор. SL необязателен для работы так что пририсуй четвертую колонку где укажи необходимость применения. Там где его нет он и не нужен.

Я уже говорил про необходимость печати с мобильных устройств, так что отсутсвие силверлайта на WinMo/iOS/Android заставляет меня вычеркнуть Silverlight из списка альтернатив.

G>А чем "просто сайты" принципиально отличаются от "бизнес приложений"? Там код какой-то другой?

Там задачи какие-то другие.

G>Я тебе привел аргументы, но ты их не увидел. Я тебе рассказал про гораздо более хорошее масштабирование и управляемость, про снижение трафика итп
G>Причем это факты. Если у тебя иногда получается как-то подругому, то это только у тебя и только иногда.

Нет, ты мне рассказал про каких-то идиотов-админов, которые не умеют администровать Windows и назвал это обоснованием применения веба.

Здравствуйте, adontz, Вы писали:

Кстати Moonlight активно пилят под андроид. http://www.geek.com/articles/mobile/moonlight-dev-crew-brings-silverlight-to-android-20110415/

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>>>уверен что большинство пользователей f5 понимают как "обновить", в вебе оно так и будет работать

A>>>Да, перезагрузит всю страницу, а надо было только элементе в списке имеющем фокус. А если список не в фокусе, то вообще ничего не делать.
G>>Для подавляющего большинства пользователей f5 — перегрузить всю страницу.
A>Это просто ограничение веба.
В смысле "ограничение"? Думаешь есть какая-то проблема в том чтобы обновить значение одного поля?
Все браузеры по f5 перегружают страницу, как и все текстовые редакторы по ctrl+c копируют текст в буфер обмена.

G>>Во-вторых смотри второй фактор. SL необязателен для работы так что пририсуй четвертую колонку где укажи необходимость применения. Там где его нет он и не нужен.

A>Я уже говорил про необходимость печати с мобильных устройств, так что отсутсвие силверлайта на WinMo/iOS/Android заставляет меня вычеркнуть Silverlight из списка альтернатив.
Я уже говорил что 0.0000001% юзкейсов вообще не интересует. Их все можно другим способом реализовать.

G>>А чем "просто сайты" принципиально отличаются от "бизнес приложений"? Там код какой-то другой?
A>Там задачи какие-то другие.
Задачи там теже самые. Достать из хранилища данные и отобразить, и записать введенные данные в хранилище + некоторые процессы, которые происходят в фоне. Принципиальная разница только в продуманности интерфейсов. Бизнес-приложения обычно содержат перегруженный функциональностью интерфейс, хреновую навигацию и довольно сильно тормозят. Публичные сайты такого себе позволить не могут.

G>>Я тебе привел аргументы, но ты их не увидел. Я тебе рассказал про гораздо более хорошее масштабирование и управляемость, про снижение трафика итп
G>>Причем это факты. Если у тебя иногда получается как-то подругому, то это только у тебя и только иногда.
A>Нет, ты мне рассказал про каких-то идиотов-админов, которые не умеют администровать Windows и назвал это обоснованием применения веба.
Ну правильно, для администрирования iis требуется на порядок меньше знаний, чем для администрирования сервера и терминалов. Кроме того веб дает гибкость, можно перемещать решение, свободно масштабировать, не требует открытых портов итп.

Здравствуйте, gandjustas, Вы писали:

G>В смысле "ограничение"? Думаешь есть какая-то проблема в том чтобы обновить значение одного поля?

Думаю есть какая-то проблема обновить значение одного поля при нажатии F5.

G>Все браузеры по f5 перегружают страницу, как и все текстовые редакторы по ctrl+c копируют текст в буфер обмена.

Мне плевать на браузеры, мне нужно обновить содержимое списка не перегружая всей страницы с помощью клавиатурного сокращения. F5 — стандарт. Невозможность использовать стандарт — ограничение веба.

G>Задачи там теже самые. Достать из хранилища данные и отобразить, и записать введенные данные в хранилище + некоторые процессы, которые происходят в фоне. Принципиальная разница только в продуманности интерфейсов. Бизнес-приложения обычно содержат перегруженный функциональностью интерфейс, хреновую навигацию и довольно сильно тормозят. Публичные сайты такого себе позволить не могут.

Забавное описание. Уровень твоей оседомлённости ясен.

A>>Нет, ты мне рассказал про каких-то идиотов-админов, которые не умеют администровать Windows и назвал это обоснованием применения веба.
G>Ну правильно, для администрирования iis требуется на порядок меньше знаний, чем для администрирования сервера и терминалов.

Это твои домыслы.

G>Кроме того веб дает гибкость, можно перемещать решение, свободно масштабировать, не требует открытых портов итп.

Не требует открытых портов? Там телепатия что ли? gandjustas, ты не показываешь преимущества веба, ты показываешь убогость своих представлений о терминале. Прекрати, это уже не забавно. У веба действительно есть преимущества объективные перед терминалом, но умудрился не назвать ни одно из них.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Все браузеры по f5 перегружают страницу, как и все текстовые редакторы по ctrl+c копируют текст в буфер обмена.
A>Мне плевать на браузеры, мне нужно обновить содержимое списка не перегружая всей страницы с помощью клавиатурного сокращения. F5 — стандарт. Невозможность использовать стандарт — ограничение веба.
f5 — стандарт для "обновить всю страницу", если ты попытаешься наделит ьэту клавишу другим поведением — пользователя не обрадуются. Все равно что сделать по ctrl-x вырезание одной буквы

G>>Задачи там теже самые. Достать из хранилища данные и отобразить, и записать введенные данные в хранилище + некоторые процессы, которые происходят в фоне. Принципиальная разница только в продуманности интерфейсов. Бизнес-приложения обычно содержат перегруженный функциональностью интерфейс, хреновую навигацию и довольно сильно тормозят. Публичные сайты такого себе позволить не могут.
A>Забавное описание. Уровень твоей оседомлённости ясен.
Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем.

A>>>Нет, ты мне рассказал про каких-то идиотов-админов, которые не умеют администровать Windows и назвал это обоснованием применения веба.
G>>Ну правильно, для администрирования iis требуется на порядок меньше знаний, чем для администрирования сервера и терминалов.
A>Это твои домыслы.
Это не домыслы, это факт. Консоль управления IIS далеко не самая сложная и не единственная часть Server manager если что.

G>>Кроме того веб дает гибкость, можно перемещать решение, свободно масштабировать, не требует открытых портов итп.
A>Не требует открытых портов? Там телепатия что ли?
Там 80-й порт, который открыт чуть более чем везде. В отличие от 3389.

A>gandjustas, ты не показываешь преимущества веба, ты показываешь убогость своих представлений о терминале. Прекрати, это уже не забавно. У веба действительно есть преимущества объективные перед терминалом, но умудрился не назвать ни одно из них.
Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу.

Ты пытаешься спорить с фактами, которые есть. Приводшь в качестве аргументов что у тебя что-то работает.

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

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:
S> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
Счегобы?

S>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.

S>Для терминальных сессий подойдут самые убитые бездискове станции.
А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".

S>Так, что у каждой технологии есть свои плюсы и минусы.
Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, gandjustas, Вы писали:
S>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
G>Счегобы?
Не все можно выполнить на сервере, а из-за этого приходится таскать данные.
S>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
G>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение.
S>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.

S>>Так, что у каждой технологии есть свои плюсы и минусы.
G>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
Ну плюсы на самом деле в денежках требуемых на программирвание этих систем, а значит является нашим хлебушком.
Я как програмиист 1С смотрю как люди мучаются с переходом 8.2. Я в своем коде стараюсь выводить большую часть выполнения кода на сервер, но много намного проще решается на клиенте. При этом в терминалах народ аж с прошлого века работает на семерках.

Здравствуйте, vmpire, Вы писали:

V>Здравствуйте, evo, Вы писали:

evo>>Здравствуйте, vmpire, Вы писали:
V>>>Что мешает "учить" и то и другое?
evo>>Такой подход мне кажется не эффективным, особенно для новичка. Это не тот случай, где технологии дополняют друг друга или идут параллельно, тут используешь или одно или другое.
evo>>Я понимаю, когда хотя б год поработал с формами, без вопросов надо учить WPF. Но что делать, когда нормально с формс еще не успел разобраться и когда МС сказали, что развивать формс больше не будут?
V>Всё зависит от цели обучения. Если цель — наработка общей эрудиции, то есть неглубокое изучение, то вполне можно учить и то и другое. Например, реализовать одну и ту же задачу на обоих технологиях, что позволит лекко увидеть сильные и слабые стороны.
V>Если целью является конкретная дальнейшая работа, то нужно смотреть, что для этой работы потребуется с большей вероятностью.

Неипите мозг, есть масса более интересных занятий, чем "учить технологии"

Мой голос хз за что

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Serginio1, Вы писали:

S>>>Здравствуйте, gandjustas, Вы писали:
S>>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
G>>Счегобы?
S> Не все можно выполнить на сервере, а из-за этого приходится таскать данные.
Как раз наоборот. Все можно и нужно выполнить на сервере, на клиенте только отображение, ввод и валидация. Если правильно готовить ajax, то получится гораздо меньше трафика, чем толстый клиент + субд или удаленный рабочий стол.

S>>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
G>>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
S> За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение.
Весь прикол в том что состояние меняется независимо от клиента. В многопользовательском окружении тебе придется выполнять те же действия. Только в вебе ты сразу так делаешь, у тебя вариантов других нет, а в толстом клиенте есть возможность сделать нехорошо.
В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.

S>>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
S> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.

S>>>Так, что у каждой технологии есть свои плюсы и минусы.
G>>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
S> Ну плюсы на самом деле в денежках требуемых на программирвание этих систем, а значит является нашим хлебушком.
S>Я как програмиист 1С смотрю как люди мучаются с переходом 8.2. Я в своем коде стараюсь выводить большую часть выполнения кода на сервер, но много намного проще решается на клиенте. При этом в терминалах народ аж с прошлого века работает на семерках.
Так 1с7.7 на терминале не от хорошей жизни, а от сложности многопользовательского развертывания и цены лицензий. Именно пытаются победить недостатки существующей версии терминальным доступом. Я предлагаю не создавать недостатки.

S>>Так, что у каждой технологии есть свои плюсы и минусы.
G>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
Ну плюсы прежде всего в хлебушке, т.к. нужно все это дело прграммировать. К 1Совец вижу как народ на 8.2 переходит и мучается, а на 7 ках еще с прошлого века на терминалах сидят и не окают.
А мне лично побарабану на чем деньги зарабатывать, но я вижу (вернее знаю на опыте) плюсы и минусы двух этих технологий.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Serginio1, Вы писали:

S>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Serginio1, Вы писали:

S>>>>Здравствуйте, gandjustas, Вы писали:
S>>>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
G>>>Счегобы?
S>> Не все можно выполнить на сервере, а из-за этого приходится таскать данные.
G>Как раз наоборот. Все можно и нужно выполнить на сервере, на клиенте только отображение, ввод и валидация. Если правильно готовить ajax, то получится гораздо меньше трафика, чем толстый клиент + субд или удаленный рабочий стол.
А афик то там только изменение экранов. Куда уж меньше то?
S>>>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
G>>>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
S>> За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение.
G>Весь прикол в том что состояние меняется независимо от клиента. В многопользовательском окружении тебе придется выполнять те же действия. Только в вебе ты сразу так делаешь, у тебя вариантов других нет, а в толстом клиенте есть возможность сделать нехорошо.
G>В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.
Ну тут множество подходов. Но если данные хранятся в БД то нефиг их вытакскивать на клиента, другое дело если делать быстрый доступ через локальные базы, за счет кэширования данных, либо стараться вычислять на сервере и передавать на клиента по быстрому каналу. Все жду недождусь, ког да же весь клиентский код можно делать в СУБД. Но ведь состояние это не только БД, но и текущий незаписанный набор данных, ограничения, данные пользователя итд.
S>>>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
S>> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
G>Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.
Только приложение тонадо написать.
S>>>>Так, что у каждой технологии есть свои плюсы и минусы.
G>>>Угу, у веба скорее плюсы, а у десктопа скорее минусы для этих самых бизнес-приложений, которые терминальным доступом пытаются закрыть.
S>> Ну плюсы на самом деле в денежках требуемых на программирвание этих систем, а значит является нашим хлебушком.
S>>Я как програмиист 1С смотрю как люди мучаются с переходом 8.2. Я в своем коде стараюсь выводить большую часть выполнения кода на сервер, но много намного проще решается на клиенте. При этом в терминалах народ аж с прошлого века работает на семерках.
G>Так 1с7.7 на терминале не от хорошей жизни, а от сложности многопользовательского развертывания и цены лицензий. Именно пытаются победить недостатки существующей версии терминальным доступом. Я предлагаю не создавать недостатки.
Нет там как раз из-за скорости, так как для dbf файлы кэшируются и скорость выполнения увеличиваются на порядки, при этом как я писал выше используются премущества локальных баз для хранения состояний, а для SQL это проще в администрировании, надежности и опять же скорости, т.к. вкладываться нужно в серверы а не в клиентские машинки.

кста , почему все решили что аппаратаное ускорение в UI даст приророст?

я могу вам сказать что даже теоретически оно может дать просадку.

потому что любой писатель 3д движков вам скажет, что часто всё упирается не в скорость видеокарты, а в скорость передачи и кол-во комманд отдаваемых ей из приложения.

поэтому в 3д движках используются всякие техники батчинга т.е. упаковки кучи буферов в одит, атласиг(упаковка кучи тестукр в одну) и прочего и строго следится за кол-вом вызовов отрисовки DrawIndexedPrimitive(DIP)
и даже крутость движка опредялется кол-вом DIPов за кадр, чем меньше — тем круче движок.

так вот я ОЧЕНЬ сомневаюсь что ВПФники такие крутые пацаны что смогли на такую сложную структуру впф приложения натянуть технологии упаковки, ибо мне это видится катастофический сложностью, потому что в 3д движках перерисовывается всегда весь экран и есть возможность собрать и подготовить данные.
А в впф нету понятия фпс, поэтому и не понятно как квантовать отрисовку для упаковки, а значит упаковки там нет и кучей мелких отрисовок можно заставить ВПФ приложение лечь.

K>А в впф нету понятия фпс, поэтому и не понятно как квантовать отрисовку для упаковки, а значит упаковки там нет и кучей мелких отрисовок можно заставить ВПФ приложение лечь.

более того, если они начнут ка-то квантовать отрисовку, то чем сильнее они начнут упаковывать, тем более тормозной отклик получат, а чем меньше упаковка тем больше команд — и тем сильнее томроза видухи

и не факт что получится найти золотую середину

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Serginio1, Вы писали:

S>>>Здравствуйте, gandjustas, Вы писали:

G>>>>Здравствуйте, Serginio1, Вы писали:

S>>>>>Здравствуйте, gandjustas, Вы писали:
S>>>>> Все таки есть разница при разработке тонкого клиента и терминалов. В терминалах намного проще программирование да во многих случаях выше призводительность.
G>>>>Счегобы?
S>>> Не все можно выполнить на сервере, а из-за этого приходится таскать данные.
G>>Как раз наоборот. Все можно и нужно выполнить на сервере, на клиенте только отображение, ввод и валидация. Если правильно готовить ajax, то получится гораздо меньше трафика, чем толстый клиент + субд или удаленный рабочий стол.
S> А афик то там только изменение экранов. Куда уж меньше то?
Угу проскроллил в одну сторону — полетели байты, проскроллил в другую сторону — аналогично, высокая чувствительность к латентности канала, на каждое нажатие клавиши раундтрип до сервера.
Если правльно готовить ajax, то передаваться будет только изменение данных. Это гораздо меньше.

S>>>>>Для тонкого клиента все равно приходится часть кода переносить на клиента, что не всегда хорошо если машинки слабенькие, следить за состоянием итд.
G>>>>Следить за состоянием как раз надо в десктопном приложении, ибо там оно неявно.
S>>> За состоянием там не надо следить, так как оно уже выполняется в необходимом контексте, а вот для клиент серверных нужно передавать, сохранять извлекать нужное состояние, что не только нетолько усложняет программирование, но и тормозит выполнение.
G>>Весь прикол в том что состояние меняется независимо от клиента. В многопользовательском окружении тебе придется выполнять те же действия. Только в вебе ты сразу так делаешь, у тебя вариантов других нет, а в толстом клиенте есть возможность сделать нехорошо.
G>>В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.
S>Но если данные хранятся в БД то нефиг их вытакскивать на клиента, другое дело если делать быстрый доступ через локальные базы, за счет кэширования данных, либо стараться вычислять на сервере и передавать на клиента по быстрому каналу. Все жду недождусь, ког да же весь клиентский код можно делать в СУБД. Но ведь состояние это не только БД, но и текущий незаписанный набор данных, ограничения, данные пользователя итд.
Ага, то есть ты сам выстраиваешь барьеры, которые уже есть в вебе.
То что ты хочешь сделать "в субд" в вебе делается на сервере, а на клиент попадает ровно то что ты скажешь. И что потом приходит с клиента на сервер ты определяешь. При хороших средствах генерации SQL на сервере пихать кастомный код в БД не имеет большого смысла.

S>>>>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>>>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
S>>> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
G>>Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.
S> Только приложение тонадо написать.
Любое приложение надо написать, из воздуха не появится.

Здравствуйте, gandjustas, Вы писали:

S>> А афик то там только изменение экранов. Куда уж меньше то?
G>Угу проскроллил в одну сторону — полетели байты, проскроллил в другую сторону — аналогично, высокая чувствительность к латентности канала, на каждое нажатие клавиши раундтрип до сервера.
G>Если правльно готовить ajax, то передаваться будет только изменение данных. Это гораздо меньше.
Так данные то хранить надо. А то народ скролить тысячами строк.
G>>>В вебе у тебя четко разграничены состояние клиента (в js и полях формы) и состояние сервера (в бд), а в десктопном приложении ты вполне скокойно можешь байндиться на коллекции объектов из ORM а потом удивляться почему savechanges сохраняет то что ты менял на предыдущем экране.
Ну с дуру то можно ...
Все о чем ты говоришь легко делается и на декстопном приложении. Разницы абсолютно никакой. Только при Вэбе приложее на клиенте, а при терминалах на сервере.
Вот и вся разница.
S>>Но если данные хранятся в БД то нефиг их вытакскивать на клиента, другое дело если делать быстрый доступ через локальные базы, за счет кэширования данных, либо стараться вычислять на сервере и передавать на клиента по быстрому каналу. Все жду недождусь, ког да же весь клиентский код можно делать в СУБД. Но ведь состояние это не только БД, но и текущий незаписанный набор данных, ограничения, данные пользователя итд.
G>Ага, то есть ты сам выстраиваешь барьеры, которые уже есть в вебе.
G>То что ты хочешь сделать "в субд" в вебе делается на сервере, а на клиент попадает ровно то что ты скажешь. И что потом приходит с клиента на сервер ты определяешь. При хороших средствах генерации SQL на сервере пихать кастомный код в БД не имеет большого смысла.
А на сервер то о откуда попадает? Ну вопервых SQL ущербен по сравнеию с C#, а на хранимые процедуры на Net накладываются ограничения. Так что так или иначе приходится тянуть код с СУБД, а вот здесь уже совсем не тонкий клиент. Межпроцессное взамодействие тормозит, а если учесть что СУБД как правило отдельно от Сервера приложений, то еще и сеть сказывается. Причем существенно, на коротких запросах.
Вобще в идеале конечно взаимодействие должно быть тонкий клиент -> СУБД, что по сути происходит при использовании локальных многопользовательских СУБД.
S>>>>>>Для терминальных сессий подойдут самые убитые бездискове станции.
G>>>>>А для веба подойдут и мобильные устройства. Их кстати больше чем "бездисковых станций".
S>>>> Но и для терминалов тоже. Да и на складе проще работать с терминалами, подключенным оборудованием итд. В том числе и офисе.
G>>>Ну если нет разницы то зачем париться? Веб доступен по-умолчанию на любом устройстве без установки доп. софта, в том числе можно браузер запусктаь в режиме киоска.
S>> Только приложение тонадо написать.
G>Любое приложение надо написать, из воздуха не появится.
Прости недопонял вопроса. Бездисковые станции с подачкой около 5 мб линукса, могут работать при минимуме ресурсов.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>все что работает через GDI работает медленнее чем через DirectX.

A>Вы не имеете ни малейшего понятия как работает видеокарта.

Нус, расскажи как с твоими познаниями "как работает видеокарта" GDI оказывается в выигрыше перед DirectX.
p.s
Попкорн с пивом купил...с нетерпением жду ответа

Здравствуйте, Аноним, Вы писали:

А>...Предположим, надо разработать отображение табличных данных по типу Excel. Будет ли достаточно winform для подобных приложений? Kак я понял из обсуждения, WPF это очень круто, но очень долго в смысле обучения, а winform это просто, но уже старо, что-ли. Так?

Главное, Silverlight для такого проекта не выбирай, ни один из поставщиков библиотек не предлагает нормальный грид, работающий с динамическими данными (костыли с кодогенерацией не в счет). Зачем вообще из силверлайта убрали ITypedList?

Здравствуйте, Kingofastellarwar, Вы писали:

K>кста , почему все решили что аппаратаное ускорение в UI даст приророст?

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

K>потому что любой писатель 3д движков....

Да хоть 4Д — они тут причём? Интерфейс — двумерный.

Здравствуйте, matumba, Вы писали:

M>Потому что видюха берёт на себя весь геморой по отображению — ей передаются лишь команды.

я там дальше написал почему "геммой по отображению" это еще не весь геморрой

M>Да хоть 4Д — они тут причём? Интерфейс — двумерный.

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

например я поставив впервые висту и включив аэро первое что отметил — огромный лаг всего интерфейса по сравнению с хр
тот же самый лаг ощущается и в любом впф приложении

Здравствуйте, Аноним, Вы писали:

А>Нус, расскажи как с твоими познаниями "как работает видеокарта" GDI оказывается в выигрыше перед DirectX.

Даю намёк для проспавших последние 10 лет в тайге: у видеокарты и процессора память не общая и любое использование GPU требует копирования данных.

Здравствуйте, gandjustas, Вы писали:

A>>Мне плевать на браузеры, мне нужно обновить содержимое списка не перегружая всей страницы с помощью клавиатурного сокращения. F5 — стандарт. Невозможность использовать стандарт — ограничение веба.
G>f5 — стандарт для "обновить всю страницу", если ты попытаешься наделит ьэту клавишу другим поведением — пользователя не обрадуются. Все равно что сделать по ctrl-x вырезание одной буквы

F5 это стандарт на "обновить". "Всю страницу" — твои домыслы.

G>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем.

Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была.

A>>Это твои домыслы.
G>Это не домыслы, это факт. Консоль управления IIS далеко не самая сложная и не единственная часть Server manager если что.

Вот именно, что это не единственная часть Server Manager.

G>Там 80-й порт, который открыт чуть более чем везде. В отличие от 3389.

Это смешно.

A>>gandjustas, ты не показываешь преимущества веба, ты показываешь убогость своих представлений о терминале. Прекрати, это уже не забавно. У веба действительно есть преимущества объективные перед терминалом, но умудрился не назвать ни одно из них.
G>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу.

Посети курс сертицикации Windows Server и там тебе ответят на эти и многие другие вопросы. Ты зашорен, не умеешь использовать возможности ОС и соё незнание выставляешь как недостатки технологиии с которой не знаком.

G>Ты пытаешься спорить с фактами, которые есть. Приводшь в качестве аргументов что у тебя что-то работает.

Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Мне плевать на браузеры, мне нужно обновить содержимое списка не перегружая всей страницы с помощью клавиатурного сокращения. F5 — стандарт. Невозможность использовать стандарт — ограничение веба.
G>>f5 — стандарт для "обновить всю страницу", если ты попытаешься наделит ьэту клавишу другим поведением — пользователя не обрадуются. Все равно что сделать по ctrl-x вырезание одной буквы

A>F5 это стандарт на "обновить". "Всю страницу" — твои домыслы.
Так работают все браузеры. И что ты думаешь люди буду ожидать нажимая f5 в браузере?

G>>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем.
A>Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была.
Ну если ты знаешь только одно приложение, то ты прав

A>>>Это твои домыслы.
G>>Это не домыслы, это факт. Консоль управления IIS далеко не самая сложная и не единственная часть Server manager если что.
A>Вот именно, что это не единственная часть Server Manager.

G>>Там 80-й порт, который открыт чуть более чем везде. В отличие от 3389.
A>Это смешно.
Ну посмейся, порты от этого не откроются.

A>>>gandjustas, ты не показываешь преимущества веба, ты показываешь убогость своих представлений о терминале. Прекрати, это уже не забавно. У веба действительно есть преимущества объективные перед терминалом, но умудрился не назвать ни одно из них.
G>>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу.
A>Посети курс сертицикации Windows Server и там тебе ответят на эти и многие другие вопросы. Ты зашорен, не умеешь использовать возможности ОС и соё незнание выставляешь как недостатки технологиии с которой не знаком.
Ответь на вопросы.

G>>Ты пытаешься спорить с фактами, которые есть. Приводшь в качестве аргументов что у тебя что-то работает.
A>Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию.
Угу, у тебя очень хорошо работает терминал если на гигабитном канале отзывчивость зависит от mtu.

Здравствуйте, gandjustas, Вы писали:

A>>F5 это стандарт на "обновить". "Всю страницу" — твои домыслы.
G>Так работают все браузеры. И что ты думаешь люди буду ожидать нажимая f5 в браузере?

Люди буду ожидать, что работает в программе, а не в браузере.

G>>>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем.
A>>Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была.
G>Ну если ты знаешь только одно приложение, то ты прав

Ничто не мешает тебе расширить список ERP, просто тебе нечем.

G>>>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу.
A>>Посети курс сертицикации Windows Server и там тебе ответят на эти и многие другие вопросы. Ты зашорен, не умеешь использовать возможности ОС и соё незнание выставляешь как недостатки технологиии с которой не знаком.
G>Ответь на вопросы.

1) Покажи способ обновить код веб-приложения остановки

Горячие патчи вызывают проблемы вне зависимости от технологии.
2) Просто берёшь и добавляешь север в NLB кластер. Создать кластер пятиминутное дело.
3) Работа в терминате с Androi dпо GPRS недоступна и вебу, потому что надо печатать. Мы уже договоролись до этого, так что не надо давать задний.

A>>Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию.
G>Угу, у тебя очень хорошо работает терминал если на гигабитном канале отзывчивость зависит от mtu.

Веб-браузер бы там вообще давно завис, так что не надо ля-ля. Ни один веб браузер не выдержит 4-5 синхронных запросов в секунду без лагов.

Здравствуйте, Kingofastellarwar, Вы писали:

Картинка слегка устаревшая. В четвертом WPF либа называется не milcore, а wpfgfx_v0400. Если верить Вики, то:

It interfaces directly with DirectX and provides basic support for 2D and 3D surfaces, timer-controlled manipulation of contents of a surface with a view to exposing animation constructs at a higher level, and compositing the individual elements of a WPF application into a final 3D "scene" that represents the UI of the application and renders it to the screen.

Так что получается, любой WPF контент считается трехмерной сценой.

Здравствуйте, gandjustas, Вы писали:

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

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>F5 это стандарт на "обновить". "Всю страницу" — твои домыслы.
G>>Так работают все браузеры. И что ты думаешь люди буду ожидать нажимая f5 в браузере?
A>Люди буду ожидать, что работает в программе, а не в браузере.
Если "программа" работает в браузере, то будут ожидать именно поведение браузера.

G>>>>Это правда жизни. Описанная выше тенденция поддерживается от наколеночных приложений до крупных продуктов от ведущих производителей. Есдиничные исключения в расчет не берем.
A>>>Опять громкие заявления без фактов. Единственный кто перешёл на веб за последнее время 1С 8.2. В итоге платформа стала ещё большим говном, чем была.
G>>Ну если ты знаешь только одно приложение, то ты прав

A>Ничто не мешает тебе расширить список ERP, просто тебе нечем.
Данивопрос: ms dynamics почти все в последних версиях переползли на веб, крупная ERP для федерального казначейства, тоже на веб переползли недавно, множество систем документооборота обзавелись веб-версиями за последние 5 лет. Это то с чем я непосредственно столкнулся.

G>>>>Ок, давай предложи сценарий обновления приложения в терминале без отключения пользователей. Покажи способ быстро добавить серваки для балансировки нагрузки. Покажи способ работы с приложением в терминале с android по GPRS каналу.
A>>>Посети курс сертицикации Windows Server и там тебе ответят на эти и многие другие вопросы. Ты зашорен, не умеешь использовать возможности ОС и соё незнание выставляешь как недостатки технологиии с которой не знаком.
G>>Ответь на вопросы.

A>1) Покажи способ обновить код веб-приложения остановки

Горячие патчи вызывают проблемы вне зависимости от технологии.

Нет, в вебе накатить новую версию можно без остановки приложения.

A>2) Просто берёшь и добавляешь север в NLB кластер. Создать кластер пятиминутное дело.

Уверен что каждый второй админ не осилит.

A>3) Работа в терминате с Androi dпо GPRS недоступна и вебу, потому что надо печатать. Мы уже договоролись до этого, так что не надо давать задний.
А если не надо печатать? терминал на GPRS сдохнет, как ни крути. Веб-версия откроется и будет работать.

A>>>Это у тебя что-то не работает. У меня и терминал работает и веб и я знаю место каждого и не пытаюськ ак ты везде протолкнуть только одну технологию.
G>>Угу, у тебя очень хорошо работает терминал если на гигабитном канале отзывчивость зависит от mtu.
A>Веб-браузер бы там вообще давно завис, так что не надо ля-ля. Ни один веб браузер не выдержит 4-5 синхронных запросов в секунду без лагов.
Что значит "синхроонных запросов"?
Как ты технически получишь 4-5 запросов в секунду?
Люди не умеют с такой скоростью производить действия.

Здравствуйте, gandjustas, Вы писали:

A>>Люди буду ожидать, что работает в программе, а не в браузере.
G>Если "программа" работает в браузере, то будут ожидать именно поведение браузера.

Браузер, в данном случае, деталь реализации. Мне надо обновить содержимое списка. Какой стандартной клавишей это сделать? У тебя нет ответа, вот и ты и пишешь нелепые отговорки.

A>>Ничто не мешает тебе расширить список ERP, просто тебе нечем.
G>Данивопрос: ms dynamics почти все в последних версиях переползли на веб, крупная ERP для федерального казначейства, тоже на веб переползли недавно, множество систем документооборота обзавелись веб-версиями за последние 5 лет. Это то с чем я непосредственно столкнулся.

Это скриншоты Dynamics NAV 2009 R2
http://www.microsoft.com/presspass/emea/presscentre/images/ConvergenceEurope/large/Alicia.jpg
http://www.microsoft.com/presspass/emea/presscentre/images/ConvergenceEurope/large/Role-Center-Drilldown.jpg

Никакого веба тут нет. gandjustas, ты либо сознательно врёшь, либо так глубоко заблуждаешься, что перестаёшь быть интересным собеседником.

A>>1) Покажи способ обновить код веб-приложения остановки

Горячие патчи вызывают проблемы вне зависимости от технологии.
G> Нет, в вебе накатить новую версию можно без остановки приложения.

Это невозможно даже в вебе. То что ты это утверждаешь, свидетельствует лишь о твоих заблуждениях.

A>>2) Просто берёшь и добавляешь север в NLB кластер. Создать кластер пятиминутное дело.
G> Уверен что каждый второй админ не осилит.

Твоя увереннось меня не убеждает. Ты наговорил столько глупостей, что ещё одна даже стоит внимания. Даже если какой-то конкретный "админ" по какой-либо причине этого не умеет, 15 минут гуглотерапии исправят ситуацию раз и навсегда.

A>>3) Работа в терминате с Androi dпо GPRS недоступна и вебу, потому что надо печатать. Мы уже договоролись до этого, так что не надо давать задний.
G>А если не надо печатать? терминал на GPRS сдохнет, как ни крути. Веб-версия откроется и будет работать.

Терминал не сдохнет, это известно из практики. Как ты можешь утверждать что терминал сдохнет, если ты не пользуешься терминалом? Тебе это приснилось?

A>>Веб-браузер бы там вообще давно завис, так что не надо ля-ля. Ни один веб браузер не выдержит 4-5 синхронных запросов в секунду без лагов.
G>Что значит "синхроонных запросов"?

Это значит что надо сделать запрос, получить на него ответ и что-то сделать (подсветить что-то цветом, например) до того как будет послан ещё один запрос.

G>Как ты технически получишь 4-5 запросов в секунду?

Я уже не раз описывал сценарии. Ты не знаком с ними, поэтому для тебя 4-5 запросов от одного клиента — восьмое чудо света. Для меня то реальность. При сканировании товара сканером штрихкода 4-5 штук в секунду самая обыкновенная скорость, бывает и ибыстрее. Сканер можут использовать и отдел продаж, и отдел логистики. Веб на таокй, типовой, задаче сливает в чистую. Но у тебя нет соответсвующего опыта и ты это просто не понимаешь. То есть совсем, потому что я уже не первый день пытаюсь тебе это объяснить. А вот терминал не сливает.

G>Люди не умеют с такой скоростью производить действия.

Бу-га-га. Добро пожаловать в реальный мир.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Люди буду ожидать, что работает в программе, а не в браузере.
G>>Если "программа" работает в браузере, то будут ожидать именно поведение браузера.

A>Браузер, в данном случае, деталь реализации. Мне надо обновить содержимое списка. Какой стандартной клавишей это сделать? У тебя нет ответа, вот и ты и пишешь нелепые отговорки.
А обычный f5 чем не устраивает?

A>>>Ничто не мешает тебе расширить список ERP, просто тебе нечем.
G>>Данивопрос: ms dynamics почти все в последних версиях переползли на веб, крупная ERP для федерального казначейства, тоже на веб переползли недавно, множество систем документооборота обзавелись веб-версиями за последние 5 лет. Это то с чем я непосредственно столкнулся.

A>Это скриншоты Dynamics NAV 2009 R2
A>http://www.microsoft.com/presspass/emea/presscentre/images/ConvergenceEurope/large/Alicia.jpg
A>http://www.microsoft.com/presspass/emea/presscentre/images/ConvergenceEurope/large/Role-Center-Drilldown.jpg

A>Никакого веба тут нет. gandjustas, ты либо сознательно врёшь, либо так глубоко заблуждаешься, что перестаёшь быть интересным собеседником.
Посмотри на Dynamics CRM 2011. Говорят вся линейка dynamics переводится на cloud, так что полюбому там веб будет.

A>>>1) Покажи способ обновить код веб-приложения остановки

Горячие патчи вызывают проблемы вне зависимости от технологии.
G>> Нет, в вебе накатить новую версию можно без остановки приложения.
A>Это невозможно даже в вебе. То что ты это утверждаешь, свидетельствует лишь о твоих заблуждениях.
Как невозможно? Я так делаю довольно часто.

A>>>3) Работа в терминате с Androi dпо GPRS недоступна и вебу, потому что надо печатать. Мы уже договоролись до этого, так что не надо давать задний.
G>>А если не надо печатать? терминал на GPRS сдохнет, как ни крути. Веб-версия откроется и будет работать.

A>Терминал не сдохнет, это известно из практики. Как ты можешь утверждать что терминал сдохнет, если ты не пользуешься терминалом? Тебе это приснилось?
Я пользуюсь терминалом и часто вижу картину как веб-приложение работает нормально, а терминальный доступ на тот же сервак тормозит. Латентность сети большая и с терминалом становится невозможно работать.

A>>>Веб-браузер бы там вообще давно завис, так что не надо ля-ля. Ни один веб браузер не выдержит 4-5 синхронных запросов в секунду без лагов.
G>>Что значит "синхроонных запросов"?
A>Это значит что надо сделать запрос, получить на него ответ и что-то сделать (подсветить что-то цветом, например) до того как будет послан ещё один запрос.
Хм... а зачем? Асинхронность как раз рулит, лучше отправить 10 запросов, а в ответ подсвечивать.

G>>Как ты технически получишь 4-5 запросов в секунду?
A>Я уже не раз описывал сценарии. Ты не знаком с ними, поэтому для тебя 4-5 запросов от одного клиента — восьмое чудо света. Для меня то реальность. При сканировании товара сканером штрихкода 4-5 штук в секунду самая обыкновенная скорость, бывает и ибыстрее. Сканер можут использовать и отдел продаж, и отдел логистики. Веб на таокй, типовой, задаче сливает в чистую. Но у тебя нет соответсвующего опыта и ты это просто не понимаешь. То есть совсем, потому что я уже не первый день пытаюсь тебе это объяснить. А вот терминал не сливает.
Ну напиши на SL приложение, которое будет фигачить эти 5 запросов в секунду, если в браузере это сложно. Веб рулит

G>>Люди не умеют с такой скоростью производить действия.
A>Бу-га-га. Добро пожаловать в реальный мир.
Реквестирую видео, где человек 5 кодов в секунду сканирует.

Здравствуйте, gandjustas, Вы писали:

G>>>Люди не умеют с такой скоростью производить действия.
A>>Бу-га-га. Добро пожаловать в реальный мир.
G>Реквестирую видео, где человек 5 кодов в секунду сканирует.

Хотя не надо. Все равно любой разговор с тобой скатывается в рассмотрение совсем нечастых кейсов. А меня эти кейсы не интересуют вообще никак.

Так что будем считать что утверждение "Бизнес-приложения (толстые клиенты трёхзвенок), лучше писать на Windows Forms" в общем случае неверно.

Здравствуйте, gandjustas, Вы писали:

A>>>>Люди буду ожидать, что работает в программе, а не в браузере.
G>>>Если "программа" работает в браузере, то будут ожидать именно поведение браузера.
A>>Браузер, в данном случае, деталь реализации. Мне надо обновить содержимое списка. Какой стандартной клавишей это сделать? У тебя нет ответа, вот и ты и пишешь нелепые отговорки.
G>А обычный f5 чем не устраивает?

Тем, что он перегружает ВСЮ страницу, а нужно только содержимое списка.

A>>Никакого веба тут нет. gandjustas, ты либо сознательно врёшь, либо так глубоко заблуждаешься, что перестаёшь быть интересным собеседником.
G>Посмотри на Dynamics CRM 2011. Говорят вся линейка dynamics переводится на cloud, так что полюбому там веб будет.

А ещё есть Office 365. Это вообще отдельный продукт, который не является заменой Microsoft Office. Cloud и Web очень разные вещи.

A>>Это невозможно даже в вебе. То что ты это утверждаешь, свидетельствует лишь о твоих заблуждениях.
G>Как невозможно? Я так делаю довольно часто.

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

A>>Это значит что надо сделать запрос, получить на него ответ и что-то сделать (подсветить что-то цветом, например) до того как будет послан ещё один запрос.
G>Хм... а зачем? Асинхронность как раз рулит, лучше отправить 10 запросов, а в ответ подсвечивать.

Пока придёт асинхронный ответ, он уже будет не актуален.

G>Ну напиши на SL приложение, которое будет фигачить эти 5 запросов в секунду, если в браузере это сложно. Веб рулит

Ну или ActiveX, ага. Веб рулит.

G>>>Люди не умеют с такой скоростью производить действия.
A>>Бу-га-га. Добро пожаловать в реальный мир.
G>Реквестирую видео, где человек 5 кодов в секунду сканирует.

Ты хоть раз видел промышленный сканер штрих-кодов? Ему для санирования хватает 50мс под любым углом. Ты просто проносишь товар в нужной области как можно быстрее.

Здравствуйте, adontz, Вы писали:

A>>>Никакого веба тут нет. gandjustas, ты либо сознательно врёшь, либо так глубоко заблуждаешься, что перестаёшь быть интересным собеседником.
G>>Посмотри на Dynamics CRM 2011. Говорят вся линейка dynamics переводится на cloud, так что полюбому там веб будет.
A>А ещё есть Office 365. Это вообще отдельный продукт, который не является заменой Microsoft Office. Cloud и Web очень разные вещи.
Cloud — инфраструктура или модель бизнеса, а работа с clud решениями идет через веб, так как он наиболее доступен.

A>>>Это невозможно даже в вебе. То что ты это утверждаешь, свидетельствует лишь о твоих заблуждениях.
G>>Как невозможно? Я так делаю довольно часто.
A>Нет, ты довольно часто копируешь новые файлы в виртуальную папку приложения поверх старых. Это не горячее обновление, это копирование файлов. Если ты не понимаешь разницу, то так и скажи.

А какая разница. Пользователь продолжает работать когда я что-то обновляю. Вэтом суть, а ты к деталям цепляешься.

A>>>Это значит что надо сделать запрос, получить на него ответ и что-то сделать (подсветить что-то цветом, например) до того как будет послан ещё один запрос.
G>>Хм... а зачем? Асинхронность как раз рулит, лучше отправить 10 запросов, а в ответ подсвечивать.
A>Пока придёт асинхронный ответ, он уже будет не актуален.
А почему тогда синхронный будет актуален? Или пусть актуальным всегда будет последний ответ.

G>>>>Люди не умеют с такой скоростью производить действия.
A>>>Бу-га-га. Добро пожаловать в реальный мир.
G>>Реквестирую видео, где человек 5 кодов в секунду сканирует.

A>Ты хоть раз видел промышленный сканер штрих-кодов? Ему для санирования хватает 50мс под любым углом. Ты просто проносишь товар в нужной области как можно быстрее.
Я не про сканер спрашиваю, а про людей, которые подносят этот товар

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, adontz, Вы писали:

A>>>>Никакого веба тут нет. gandjustas, ты либо сознательно врёшь, либо так глубоко заблуждаешься, что перестаёшь быть интересным собеседником.
G>>>Посмотри на Dynamics CRM 2011. Говорят вся линейка dynamics переводится на cloud, так что полюбому там веб будет.
A>>А ещё есть Office 365. Это вообще отдельный продукт, который не является заменой Microsoft Office. Cloud и Web очень разные вещи.
G>Cloud — инфраструктура или модель бизнеса, а работа с clud решениями идет через веб, так как он наиболее доступен.

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

G>>>Как невозможно? Я так делаю довольно часто.
A>>Нет, ты довольно часто копируешь новые файлы в виртуальную папку приложения поверх старых. Это не горячее обновление, это копирование файлов. Если ты не понимаешь разницу, то так и скажи.
G>

G>А какая разница. Пользователь продолжает работать когда я что-то обновляю. Вэтом суть, а ты к деталям цепляешься.

ОМГ, а что будет если скопировалась только половина файлов и поступил запрос? Это не детали, gandjustas, это твоя дремучая безграмотность в обсуждаемом вопросе.

A>>Пока придёт асинхронный ответ, он уже будет не актуален.
G>А почему тогда синхронный будет актуален? Или пусть актуальным всегда будет последний ответ.

Например, сканируем товары в заказе, проверяем packing list. Человек проносит товар мимо сканера, это делает очень быстро. Надо успеть сообщить (обычно звуком) что товара нет в заказе и он сканируется что-то лишнее, до того как оператор отпустит товар из рук. То есть время отклика — миллисекунды.

A>>Ты хоть раз видел промышленный сканер штрих-кодов? Ему для санирования хватает 50мс под любым углом. Ты просто проносишь товар в нужной области как можно быстрее.
G>Я не про сканер спрашиваю, а про людей, которые подносят этот товар

Когда маленький был, жонглёра в цирке видел? Ну так вот, дядя сменил работу.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, adontz, Вы писали:

A>>>>>Никакого веба тут нет. gandjustas, ты либо сознательно врёшь, либо так глубоко заблуждаешься, что перестаёшь быть интересным собеседником.
G>>>>Посмотри на Dynamics CRM 2011. Говорят вся линейка dynamics переводится на cloud, так что полюбому там веб будет.
A>>>А ещё есть Office 365. Это вообще отдельный продукт, который не является заменой Microsoft Office. Cloud и Web очень разные вещи.
G>>Cloud — инфраструктура или модель бизнеса, а работа с clud решениями идет через веб, так как он наиболее доступен.

A>Ты действительно не понимаешь разницы между услугой доступной через веб и продуктом с веб-интерфейсом?
Я тебе выше написал. ты читаешь вообще?

G>>>>Как невозможно? Я так делаю довольно часто.
A>>>Нет, ты довольно часто копируешь новые файлы в виртуальную папку приложения поверх старых. Это не горячее обновление, это копирование файлов. Если ты не понимаешь разницу, то так и скажи.
G>>

G>>А какая разница. Пользователь продолжает работать когда я что-то обновляю. Вэтом суть, а ты к деталям цепляешься.

A>ОМГ, а что будет если скопировалась только половина файлов и поступил запрос?
Я так понимаю webdeploy умеет с этим обходиться.

A>Это не детали, gandjustas, это твоя дремучая безграмотность в обсуждаемом вопросе.
Может и безграмотность, но я могу так сделать, а ты в терминале — нет

A>>>Пока придёт асинхронный ответ, он уже будет не актуален.
G>>А почему тогда синхронный будет актуален? Или пусть актуальным всегда будет последний ответ.

A>Например, сканируем товары в заказе, проверяем packing list. Человек проносит товар мимо сканера, это делает очень быстро. Надо успеть сообщить (обычно звуком) что товара нет в заказе и он сканируется что-то лишнее, до того как оператор отпустит товар из рук. То есть время отклика — миллисекунды.
У меня раундтрип через океан с лукапами по базе занимает 200 мс. В локальной сети на гигабитном канале это и будет десяток миллисекунд. опять таки вопрос только в пропускной способности сети и правильном использовании канала. Только в вебе я сам говорю что отправлять, а в терминале нет и латентность сети там больше имеет значение.

Здравствуйте, gandjustas, Вы писали:

A>>Это не детали, gandjustas, это твоя дремучая безграмотность в обсуждаемом вопросе.
G>Может и безграмотность, но я могу так сделать, а ты в терминале — нет

Да, возможность при обновлении поломать инсталляцию это преимущество веба.

G>У меня раундтрип через океан с лукапами по базе занимает 200 мс. В локальной сети на гигабитном канале это и будет десяток миллисекунд. опять таки вопрос только в пропускной способности сети и правильном использовании канала. Только в вебе я сам говорю что отправлять, а в терминале нет и латентность сети там больше имеет значение.

Да-да-да, у XmlHttpRequest в браузере не будет лагов. Верь в это.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Это не детали, gandjustas, это твоя дремучая безграмотность в обсуждаемом вопросе.
G>>Может и безграмотность, но я могу так сделать, а ты в терминале — нет

A>Да, возможность при обновлении поломать инсталляцию это преимущество веба.

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

G>>У меня раундтрип через океан с лукапами по базе занимает 200 мс. В локальной сети на гигабитном канале это и будет десяток миллисекунд. опять таки вопрос только в пропускной способности сети и правильном использовании канала. Только в вебе я сам говорю что отправлять, а в терминале нет и латентность сети там больше имеет значение.

A>Да-да-да, у XmlHttpRequest в браузере не будет лагов. Верь в это.
Я такое лучше на SL сделаю, у XmlHttpRequest может и не будет лагов, но однопоточный js может слажать.

Здравствуйте, gandjustas, Вы писали:

G>>>Может и безграмотность, но я могу так сделать, а ты в терминале — нет

A>>Да, возможность при обновлении поломать инсталляцию это преимущество веба.
G>А кто тебе мешает просто поудалять файлы любого приложения? Причем тут веб вообще?

Да ты как бы впаривал что бывают горячие обновления

Почитай лучше про graceful restart, это безумно сложная задача которая в IIS не решена.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>>>Может и безграмотность, но я могу так сделать, а ты в терминале — нет

A>>>Да, возможность при обновлении поломать инсталляцию это преимущество веба.
G>>А кто тебе мешает просто поудалять файлы любого приложения? Причем тут веб вообще?

A>Да ты как бы впаривал что бывают горячие обновления

Почитай лучше про graceful restart, это безумно сложная задача которая в IIS не решена.

Видимо за ненадобностью

Здравствуйте, gandjustas, Вы писали:

A>>Да ты как бы впаривал что бывают горячие обновления

Почитай лучше про graceful restart, это безумно сложная задача которая в IIS не решена.
G>Видимо за ненадобностью

Но ты доказывал что она решена и ты можешь, в отличие от RDP, пользоваться этим решением. Следовательно, ты не прав.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Да ты как бы впаривал что бывают горячие обновления

Почитай лучше про graceful restart, это безумно сложная задача которая в IIS не решена.
G>>Видимо за ненадобностью

A>Но ты доказывал что она решена и ты можешь, в отличие от RDP, пользоваться этим решением. Следовательно, ты не прав.

Еще раз суть: я могу обносить приложение без прерывания работы пользователей, ты — нет. Ты начал напирать на очередной кране редкий кейс, что пройдет запрос когда еще не все файлы обновлены, тем не менее он не отменяет того факта что я могу так сделать.

Здравствуйте, gandjustas, Вы писали:

A>>Но ты доказывал что она решена и ты можешь, в отличие от RDP, пользоваться этим решением. Следовательно, ты не прав.
G>Еще раз суть: я могу обносить приложение без прерывания работы пользователей, ты — нет. Ты начал напирать на очередной кране редкий кейс, что пройдет запрос когда еще не все файлы обновлены, тем не менее он не отменяет того факта что я могу так сделать.

Да ты и транзакциями не пользуешься, наверное. Маловероятно чтобы два пользователя редактировали одни и те же данные.

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

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Но ты доказывал что она решена и ты можешь, в отличие от RDP, пользоваться этим решением. Следовательно, ты не прав.
G>>Еще раз суть: я могу обносить приложение без прерывания работы пользователей, ты — нет. Ты начал напирать на очередной кране редкий кейс, что пройдет запрос когда еще не все файлы обновлены, тем не менее он не отменяет того факта что я могу так сделать.

A>Да ты и транзакциями не пользуешься, наверное. Маловероятно чтобы два пользователя редактировали одни и те же данные.
А причем тут транзакции?

A>gandjustas, ты просто продемонстрировал полное непонимание общеизвестных проблем, отсутсвие знаний об общепринятых решениях этих проблем, бросался лозунгами, регулярно предоставлял заведомо ложную информацию, истинность которой проверяться 5 минутами в гугле. Тебе не стыдно?
Каких проблем? ты часто видел чтобы при обновлении веб-приложениий происходили эффекты, о которых ты говоришь? Я вот не видел, хотя вебом занимаюсь гораздо больше тебя.

Практика как всегда критерий истины, и именно она подсказывает что в общем случае выгоднее делать бизнес-приложения на вебе, чем на десктомных технологиях. Частные случаи, в которых верно обратное остаются частными случаями. Можешь еще хоть сто сообщений написать про печать со смартфона, 10 сканирований в секунду, летающий remote desktop, выполнение запроса между перезаписями файлов на сервере но на практике такого один на миллион.

Здравствуйте, gandjustas, Вы писали:

G>>>Еще раз суть: я могу обносить приложение без прерывания работы пользователей, ты — нет. Ты начал напирать на очередной кране редкий кейс, что пройдет запрос когда еще не все файлы обновлены, тем не менее он не отменяет того факта что я могу так сделать.
A>>Да ты и транзакциями не пользуешься, наверное. Маловероятно чтобы два пользователя редактировали одни и те же данные.
G>А причем тут транзакции?

Спасибо, теперь всё с тобой предельно ясно.

Здравствуйте, MxMsk, Вы писали:

MM>Так что получается, любой WPF контент считается трехмерной сценой.

ессно,и я вообще думал что наши впфники догадываются откуда растут ноги у впфных шейдеров, 3д трансформаций, способов задания 3д объектов и прочего

Здравствуйте, Kingofastellarwar, Вы писали:

MM>>Так что получается, любой WPF контент считается трехмерной сценой.
K>ессно,и я вообще думал что наши впфники догадываются откуда растут ноги у впфных шейдеров, 3д трансформаций, способов задания 3д объектов и прочего
Ну кто его знает, как они там оптимизируют. Может используют Direct3D только там, где есть смысл в 3D. Да и я не знаток DirectX

Здравствуйте, gandjustas, Вы писали:

G>Практика как всегда критерий истины, и именно она подсказывает что в общем случае выгоднее делать бизнес-приложения на вебе, чем на десктомных технологиях. Частные случаи, в которых верно обратное остаются частными случаями. Можешь еще хоть сто сообщений написать про печать со смартфона, 10 сканирований в секунду, летающий remote desktop, выполнение запроса между перезаписями файлов на сервере но на практике такого один на миллион.
Господи, ну это же полная чушь. Как только в ветку приходит gandjustas, она сразу превращается в простыню водяных сообщений с кучей базвордов и, как уже было верно подмечено, заведомо ложной информацией. Спор превращается в пустой треп

Здравствуйте, MxMsk, Вы писали:

MM>Здравствуйте, gandjustas, Вы писали:

G>>Практика как всегда критерий истины, и именно она подсказывает что в общем случае выгоднее делать бизнес-приложения на вебе, чем на десктомных технологиях. Частные случаи, в которых верно обратное остаются частными случаями. Можешь еще хоть сто сообщений написать про печать со смартфона, 10 сканирований в секунду, летающий remote desktop, выполнение запроса между перезаписями файлов на сервере но на практике такого один на миллион.
MM>Господи, ну это же полная чушь.
Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?

Здравствуйте, gandjustas, Вы писали:

G>Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?

Да и то, и другое

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?

A>Да и то, и другое

Доказательства?

Здравствуйте, gandjustas, Вы писали:

G>>>Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?
A>>Да и то, и другое

G>Доказательства?

Э нет, это мой вопрос. Где доказательства, что на вебе делается больше приложений? Про печать со смартфона я с тобой даже говорить не хочу, ещё вчера ты понятия не имел что принтер может быть установлен в машине торогового агента. Сперва наберись опыта, а потом обсуждай энтерпрайз.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>>>Товарищ, что из этого чушь? То что большинство приложений делается на вебе? Или то что печать со смартфона — очень редкий кейс?
A>>>Да и то, и другое

G>>Доказательства?

A>Э нет, это мой вопрос. Где доказательства, что на вебе делается больше приложений?
Прямых как-бы нет. Никто точно не скажет. Но гугл по запросу "web business application" выдает в 2 раза больше результатов, чем "desktop business application", да и статистика потребностей технологий что здесь приводилась тоже косвенно о таком говорит.

A>Про печать со смартфона я с тобой даже говорить не хочу, ещё вчера ты понятия не имел что принтер может быть установлен в машине торогового агента.
Не меняй тему.

A>Сперва наберись опыта, а потом обсуждай энтерпрайз.
Мне опыта хватает, я кучу разных "энтерпрайзов" видел.

Здравствуйте, gandjustas, Вы писали:

A>>Э нет, это мой вопрос. Где доказательства, что на вебе делается больше приложений?
G>Прямых как-бы нет.

Ну вот и ладненько.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Э нет, это мой вопрос. Где доказательства, что на вебе делается больше приложений?
G>>Прямых как-бы нет.

A>Ну вот и ладненько.

Ок, съехал.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>Нус, расскажи как с твоими познаниями "как работает видеокарта" GDI оказывается в выигрыше перед DirectX.

A>Даю намёк для проспавших последние 10 лет в тайге: у видеокарты и процессора память не общая и любое использование GPU требует копирования данных.

Круто !
Только для тех кто в тайге :

1) Видеокарта позволяет копировать данные не только из памяти с которой работает процессор, у нее есть собственная
Например картинку на кнопке WPF загружает в видеопамять как текстуру и ее "копирование" из видеопаямти в видеопамять занимает намного меньше времени

2) Уже давно для плоской графики используется Direct3d , чтобы отрисовать прямоугольник для кнопки достаточно передать координаты вершин и цвет, не нужно копировать каждый пиксель. Для кнопки 50х20 ~ 4 кб информации по каждому пикселю, в случае DirectX < 100 байт.
3) GDI при операциях с видео осуществляет переключение в режим ядра, что существенно замедляет работу, в отличии от DirectX, который собственно для этого и создавали чтобы работать на прямую.

Но ты так и не раскрыл тайну о своих "познаниях как работает видеокарта" , которые позволяют производить какую либо отрисовку через GDI быстрее чем это можно сделать через DirectX.

Ушел за следующей порцией попкорна.

Здравствуйте, Аноним, Вы писали:

я отвечу

А>1) Видеокарта позволяет копировать данные не только из памяти с которой работает процессор, у нее есть собственная
А>Например картинку на кнопке WPF загружает в видеопамять как текстуру и ее "копирование" из видеопаямти в видеопамять занимает намного меньше времени

операция загрузки текстуры относительно медленная это раз,
два, тестура хранится целиком и занимает видео память, и если вам нужно отрисовать 10 тыщ картинок, то в GDI вы упретесь только в размер основной памяти, а в Direct3D у вас в распоряжении только видеопамять
причем вы эту память еще и с другими 3д приложениями делите и сам загрузка 10 тыщ изображдений не такая уж и быстрая и 10000 команд тоже не быстро будут обработаны, потому что сначала изменения помещаются в очередь вфп, а из неё в очередь графического проца, а потом еще дождаться презентации буфера — вот отсюда ноги лага растут всего что Direct3d использует, а в ГДИ всё рисуется напрямую одним вызовом и с немедленным отображением результата.
именно поэтому все современные игры сначала загружают данные в видеопамять, а потом запускают уровень, потому что ЦПУ-ГПУ это до сих пор очень узкое место.

в общем: если у вас 2д изображение часто и непредсказуемо меняется(например что-то рисуется), а не лепится из 10-20 кубиков, то впф будет сливаться по сравниению с гди, если бы это было не так мы бы уже давно имели принципиально новые 3д игры.
потому что заливка и особенно модификация данных в видеопамяти со стороны ЦПУ — это жопа, а логика у вас крутится на ЦПУ.
причем 3д играм проще, чем впф — они имеют право практически монопольно жрать весь ЦПУ и соотв использовать быстрые ожидания типа while(ждать_готовности_гпу) и получать максимальный фпс;
а впф такое запрещено, все ожидания должны быть сделаны через примитивы синхронизации.
поэтому в играх наш лаг можно сжать до минимума.

А>2) Уже давно для плоской графики используется Direct3d , чтобы отрисовать прямоугольник для кнопки достаточно передать координаты вершин и цвет, не нужно копировать каждый пиксель. Для кнопки 50х20 ~ 4 кб информации по каждому пикселю, в случае DirectX < 100 байт.

это тот слуай где 3д быстрее, но есть много случаев где он плох.
например вам нужно нарисовать случайное 2д изображение — для 3д это жопа. если вы не знали, у Direct3D вообще нет функций рисования, потому что там всё — геометрия, единственная функция — это залить цветом прямоугольник в текстуре.

А>3) GDI при операциях с видео осуществляет переключение в режим ядра, что существенно замедляет работу, в отличии от DirectX, который собственно для этого и создавали чтобы работать на прямую.

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

а DirectX назван не потому что вы с видухой напрямую общаетесь, а потому что это простенькая надстройка над драйвером, причем для GDI и DirectX драйвер реализует разный АПИ.
т.е. GDI не работает через DirectX, это независимая от DirectX функциональность, как минимум потому что она была до DirectX

Здравствуйте, Kingofastellarwar, Вы писали:

K>Здравствуйте, Аноним, Вы писали:

K>я отвечу

А>>1) Видеокарта позволяет копировать данные не только из памяти с которой работает процессор, у нее есть собственная
А>>Например картинку на кнопке WPF загружает в видеопамять как текстуру и ее "копирование" из видеопаямти в видеопамять занимает намного меньше времени

K>операция загрузки текстуры относительно медленная это раз,
Это делается один раз. А не на каждую перерисовку формы, как в случае GDI.

K>два, тестура хранится целиком и занимает видео память, и если вам нужно отрисовать 10 тыщ картинок, то в GDI вы упретесь только в размер основной памяти, а в Direct3D у вас в распоряжении только видеопамять

Даже 10 тыщ иконок для кнопок по 4 кб каждая займут 40 Мб видеопамяти. Но даже в случае ее дефицита WPF может размещать данные и в оперативной памяти.
Так что он использует преимущество пока оно возможно. А GDI тормозит всегда.
В случае GDI порядка 10 тыщ кнопок вам вообще будет сложно сделать

Each time a window is opened, it consumes GDI objects. As the complexity of the window increases, with additional features such as buttons and images, its GDI object usage also increases. When too many objects are in use, Windows is unable to draw any more GDI objects, leading to misbehaving software and frozen and unresponsive program operation. [8][9] The total available GDI objects varies from one version of Windows to the next: Windows 95, 98, and Millennium had a limit of 1,200 total objects; Windows 2000 has a limit of 16,384 objects; and Windows XP, Vista, and Windows 7 have a configurable limit (via the registry) that defaults to 10,000 objects per process

K>причем вы эту память еще и с другими 3д приложениями делите и сам загрузка 10 тыщ изображдений не такая уж и быстрая и 10000 команд тоже не быстро будут обработаны, потому что сначала изменения помещаются в очередь вфп, а из неё в очередь графического проца, а потом еще дождаться презентации буфера — вот отсюда ноги лага растут всего что Direct3d использует, а в ГДИ всё рисуется напрямую одним вызовом и с немедленным отображением результата.

В GDI рисуется не все сразу а только то что делает конкретная команда, Rectangle, SetPixel и т.п.
Причем каждая команда вызывает переключение в режим ядра, что помимо копирования в видео создает дополнительные тормоза.
Попробуйте закрасить форму случайными пикселями при помощи GDI и сравните насколько быстрее это будет через DirectX, на 2 порядка.

K>именно поэтому все современные игры сначала загружают данные в видеопамять, а потом запускают уровень, потому что ЦПУ-ГПУ это до сих пор очень узкое место.

Именно поэтому современные игры пишутся на DirectX, а не на GDI. Потому что GDI заведомо тормоз.

K>в общем: если у вас 2д изображение часто и непредсказуемо меняется(например что-то рисуется), а не лепится из 10-20 кубиков, то впф будет сливаться по сравниению с гди, если бы это было не так мы бы уже давно имели принципиально новые 3д игры.

Если бы было по вашему то современные игры писали бы на GDI, однако я и другие разработчики предпочитают DirectX.

K>потому что заливка и особенно модификация данных в видеопамяти со стороны ЦПУ — это жопа, а логика у вас крутится на ЦПУ.
поэтому GDI и тормоз, т.к. он все делает на уровне ЦПУ, WPF использует возможности DirectX, для акселерации того же альфа-канала.

K>причем 3д играм проще, чем впф — они имеют право практически монопольно жрать весь ЦПУ и соотв использовать быстрые ожидания типа while(ждать_готовности_гпу) и получать максимальный фпс;

В играх много расчетов , в том числе физики. Например WinRar при архивации сжирает ЦПУ не меньше, однако никаких обновлений экрана не использует.

K>а впф такое запрещено, все ожидания должны быть сделаны через примитивы синхронизации.
K>поэтому в играх наш лаг можно сжать до минимума.
В WPF ничего не запрещено, вы можете использовать по необходимости то что реально требуется.

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

А>>2) Уже давно для плоской графики используется Direct3d , чтобы отрисовать прямоугольник для кнопки достаточно передать координаты вершин и цвет, не нужно копировать каждый пиксель. Для кнопки 50х20 ~ 4 кб информации по каждому пикселю, в случае DirectX < 100 байт.

K>это тот слуай где 3д быстрее, но есть много случаев где он плох.
K>например вам нужно нарисовать случайное 2д изображение — для 3д это жопа. если вы не знали, у Direct3D вообще нет функций рисования, потому что там всё — геометрия, единственная функция — это залить цветом прямоугольник в текстуре.
Слишком бедные у вас представления, а как же вершинные и пискельные шейдеры, на которых можно сделать практически любую анимацию без постоянной передачи данных от ЦПУ в ГПУ.
Понятие случайное 2D изображение для бизнес приложения это какой-то бред. Когда в тех же играх делают "шум" из пикселей раньше использовали готовые текстурки с рандомными пикселями, сейчас используют шейдеры.
Но в бизнес приложениях с обычными кнопками это вообще не нужно.

А>>3) GDI при операциях с видео осуществляет переключение в режим ядра, что существенно замедляет работу, в отличии от DirectX, который собственно для этого и создавали чтобы работать на прямую.

K>неверно,
K>данные в GPU может передавать только кернел-драйвер, это именно тот который вы ставите чтобы видуха заработала, а он работает с портами и поэтому не может не быть в 0 кольце

Речь не про драйвер а про взаимодействие USER приложение через GDI с драйвером.

K>т.е. GDI не работает через DirectX, это независимая от DirectX функциональность, как минимум потому что она была до DirectX

само собой. Читайте выше.

Я и не говорил что GDI работает через DirectX, подумайте лучше зачем сделали DirectX когда была GDI.

И собственно так и не дали самого важного ответа — приведите конкретный практический пример любой отрисовки ( можно в исходном коде ) где GDI будет быстрее DirectX.
Все ваши попытки как-то представить белое черным как раз противоречат практике , которая подтверждает что GDI на порядок тормознее чем отрисовка через DirectX.

Здравствуйте, Аноним, Вы писали:

K>>операция загрузки текстуры относительно медленная это раз,
А>Это делается один раз. А не на каждую перерисовку формы, как в случае GDI.

Медленный старт приложений крайне характерен для WPF. Причём, когда я говорю медленный, я имею ввиду десятки секунд и минуты. Помимо прочего, вы предполагаете что все текстуры поместятся в видео-память. Это, вообще говоря, не всегда правда и тогда загрудка в видео-память может повторятся. Кроме того, DirectX, через который работает WPF, может по своей воле выгружать текстуры из видео-памяти. WPF использует DirectX в неэксклюзивном режиме и вытеснение WPF приложения нормальная ситуация. Интенсивное использование видеопамяти в неэксклюзивном режиме весьма неудачная практика. Если с обычной памятью GC может производить дефрагментацию, то с видео-памятью такого сделать нельзя. Получаем с WPF старые известные проблемы, которые уже встречались при использовании Large Object Heap. WPF фрагментирует видео-память. Это неизбежно. Как и в случае с LOH, это может приводить (и приводит) к досрочным OutOfMemory.

А>Даже 10 тыщ иконок для кнопок по 4 кб каждая займут 40 Мб видеопамяти. Но даже в случае ее дефицита WPF может размещать данные и в оперативной памяти.

Нет. В оперативное памяти текстуры находятся всегда. Прости некоторые из них находятся ещё и в видео-памяти. Потом вы в корне не правы расчитывая объём текстур. Надо понимать что разного рода эффекты могут требовать дополнительных redder target, так что под окно может быть более двух (а два есть всегда) буферов.

А>

А>Each time a window is opened, it consumes GDI objects. As the complexity of the window increases, with additional features such as buttons and images, its GDI object usage also increases. When too many objects are in use, Windows is unable to draw any more GDI objects, leading to misbehaving software and frozen and unresponsive program operation. [8][9] The total available GDI objects varies from one version of Windows to the next: Windows 95, 98, and Millennium had a limit of 1,200 total objects; Windows 2000 has a limit of 16,384 objects; and Windows XP, Vista, and Windows 7 have a configurable limit (via the registry) that defaults to 10,000 objects per process

Объекты GDI не имеют вообще никакого отношения к возможности отрисовать 10000 текстур. Вы плохо знаете GDI.

А>В GDI рисуется не все сразу а только то что делает конкретная команда, Rectangle, SetPixel и т.п.

Вы приводете заведомо ложные факты. GdiGetBatchLimit, GdiSetBatchLimit, GdiFlush.

А>Причем каждая команда вызывает переключение в режим ядра, что помимо копирования в видео создает дополнительные тормоза.

Смю выше.

K>>именно поэтому все современные игры сначала загружают данные в видеопамять, а потом запускают уровень, потому что ЦПУ-ГПУ это до сих пор очень узкое место.
А>Именно поэтому современные игры пишутся на DirectX, а не на GDI. Потому что GDI заведомо тормоз.

Да нет, для многих современных(!) игр DirectX такой overkill, что придумали Direct2D. Причём Direct2D придумали даже не потому что GDI чем-то не устраивал, а потому что там архитектурная жопа с разного рода прозрачностями.

А>Если бы было по вашему то современные игры писали бы на GDI, однако я и другие разработчики предпочитают DirectX.

Разработчики игр пишут не на DX/OGL, а на ешйдерах, это дань моде. Шейдеры из GDI не доступны. Скорость отрисовки тут уже не так важна. GDI ещё использует аппаратное ускорение, а вот есть в Windows програмный рендерер WARP10, применяемый в терминальной сессии. На нём Crysis даёт не меньше 5 FPS на i5. Так что для большиства казуальных игр скорости GDI хватает выше крыши и причины использования DirectX совсем другие.

K>>потому что заливка и особенно модификация данных в видеопамяти со стороны ЦПУ — это жопа, а логика у вас крутится на ЦПУ.
А>поэтому GDI и тормоз, т.к. он все делает на уровне ЦПУ, WPF использует возможности DirectX, для акселерации того же альфа-канала.

Вы опять приводете заведомо ложные факты. GDI не всё делает через CPU. http://msdn.microsoft.com/en-us/library/ff729480%28VS.85%29.aspx

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

А отчёты?

А>Слишком бедные у вас представления, а как же вершинные и пискельные шейдеры, на которых можно сделать практически любую анимацию без постоянной передачи данных от ЦПУ в ГПУ.

А как же Intel GMA? Или по вашему в офисном компьютере сплошь последние GeForce'ы? Наивные вещи говорите.

А>Я и не говорил что GDI работает через DirectX, подумайте лучше зачем сделали DirectX когда была GDI.

DirectX был заменой WinG/DCI а вовсе не GDI.

А>И собственно так и не дали самого важного ответа — приведите конкретный практический пример любой отрисовки ( можно в исходном коде ) где GDI будет быстрее DirectX.
А>Все ваши попытки как-то представить белое черным как раз противоречат практике, которая подтверждает что GDI на порядок тормознее чем отрисовка через DirectX.

Практически любые аналитические графики.

Здравствуйте, Аноним, Вы писали:

А>Даже 10 тыщ иконок для кнопок по 4 кб каждая займут 40 Мб видеопамяти. Но даже в случае ее дефицита WPF может размещать данные и в оперативной памяти.
А>Так что он использует преимущество пока оно возможно. А GDI тормозит всегда.
А>В случае GDI порядка 10 тыщ кнопок вам вообще будет сложно сделать

мне не обязательо хранить хендлы для всех картинок, которые нада нарисовать.

А>В GDI рисуется не все сразу а только то что делает конкретная команда, Rectangle, SetPixel и т.п.
А>Причем каждая команда вызывает переключение в режим ядра, что помимо копирования в видео создает дополнительные тормоза.
А>Попробуйте закрасить форму случайными пикселями при помощи GDI и сравните насколько быстрее это будет через DirectX, на 2 порядка.

ну вы просто не в курсе, обращение напрямую к данным текстуры это операция которая еще медленнее чем любой GDI вызов, настолько медленная, что в комменде разработчкиов 3д движка можно по роже получить за использование ее там, где ее необходимость не критическая

А>Именно поэтому современные игры пишутся на DirectX, а не на GDI. Потому что GDI заведомо тормоз.

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

и потому что там есть 3D API.
но и там можно GDI использовать если нужно что-то рисовать, IDirect3DSurface9->GetDC и вперёд.

А>Если бы было по вашему то современные игры писали бы на GDI, однако я и другие разработчики предпочитают DirectX.

что-то не заметно, что вы директ знаете

А>В WPF ничего не запрещено, вы можете использовать по необходимости то что реально требуется.
вы будете считать нормальным десктопное впф приложение которые ест весь цпу?

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

А>Слишком бедные у вас представления, а как же вершинные и пискельные шейдеры, на которых можно сделать практически любую анимацию без постоянной передачи данных от ЦПУ в ГПУ.
А>Понятие случайное 2D изображение для бизнес приложения это какой-то бред. Когда в тех же играх делают "шум" из пикселей раньше использовали готовые текстурки с рандомными пикселями, сейчас используют шейдеры.
А>Но в бизнес приложениях с обычными кнопками это вообще не нужно.

вы вообще пиксельный или вершинный шедер хоть раз писали? попробуйте как вам говорят выше репорт нарисовать шейдерами

шейдеры это эффекты, они делают одно сложное преобразование и всё.

А>Речь не про драйвер а про взаимодействие USER приложение через GDI с драйвером.

это всё не важно и ГДИ и ВФП в итоге отсылает данные драйверу, в любом случае.

А>И собственно так и не дали самого важного ответа — приведите конкретный практический пример любой отрисовки ( можно в исходном коде ) где GDI будет быстрее DirectX.
А>Все ваши попытки как-то представить белое черным как раз противоречат практике , которая подтверждает что GDI на порядок тормознее чем отрисовка через DirectX.

к примеру — рендер HTML`я, и Firefox5 тому пример, жрет больше, а толку не видно

Здравствуйте, adontz, Вы писали:

A>Медленный старт приложений крайне характерен для WPF. Причём, когда я говорю медленный, я имею ввиду десятки секунд и минуты. Помимо прочего, вы предполагаете что все текстуры поместятся в видео-память. Это, вообще говоря, не всегда правда и тогда загрудка в видео-память может повторятся. Кроме того, DirectX, через который работает WPF, может по своей воле выгружать текстуры из видео-памяти. WPF использует DirectX в неэксклюзивном режиме и вытеснение WPF приложения нормальная ситуация. Интенсивное использование видеопамяти в неэксклюзивном режиме весьма неудачная практика. Если с обычной памятью GC может производить дефрагментацию, то с видео-памятью такого сделать нельзя. Получаем с WPF старые известные проблемы, которые уже встречались при использовании Large Object Heap. WPF фрагментирует видео-память. Это неизбежно. Как и в случае с LOH, это может приводить (и приводит) к досрочным OutOfMemory.

тут я честно говоря не уверен, в директх данные в видеопамяти хранятся в управялемой куче и чтобы получить указатель на что-то в видеопамяти нада делать Lock/Unlock
и я так понимаю он как минимум может делать дефрагментацию, а делает или нет это вопрос. мож и не делает

но всё остальное — верно

Здравствуйте, Kingofastellarwar, Вы писали:

K>тут я честно говоря не уверен, в директх данные в видеопамяти хранятся в управялемой куче и чтобы получить указатель на что-то в видеопамяти нада делать Lock/Unlock
K>и я так понимаю он как минимум может делать дефрагментацию, а делает или нет это вопрос. мож и не делает

K>но всё остальное — верно

Для дефрагментации нужно два условия
1) Двойная косвенность: указатель на указатель на память.
2) Копирование данных.

Я легко могу поверить в первое, но в то что DirectX копирует текстуры из одной области видеопамяти в другой (да ещё и по своей воле) верится с трудом.

Lock/Unlock это не pin памяти, а копирование. В Lock/Map передаётся LockFlags/D3D11_MAP в которых указано что можно делать, а что нельзя. Если бы это был просто pin, зачем возможность делать read-only/write-only Lock/Map?

Здравствуйте, adontz, Вы писали:

A>Медленный старт приложений крайне характерен для WPF. Причём, когда я говорю медленный, я имею ввиду десятки секунд и минуты.
И все же это характерно только для первого старта. Последующие гораздо быстрее.

A>Помимо прочего, вы предполагаете что все текстуры поместятся в видео-память. Это, вообще говоря, не всегда правда и тогда загрудка в видео-память может повторятся. Кроме того, DirectX, через который работает WPF, может по своей воле выгружать текстуры из видео-памяти. WPF использует DirectX в неэксклюзивном режиме и вытеснение WPF приложения нормальная ситуация. Интенсивное использование видеопамяти в неэксклюзивном режиме весьма неудачная практика. Если с обычной памятью GC может производить дефрагментацию, то с видео-памятью такого сделать нельзя. Получаем с WPF старые известные проблемы, которые уже встречались при использовании Large Object Heap. WPF фрагментирует видео-память. Это неизбежно. Как и в случае с LOH, это может приводить (и приводит) к досрочным OutOfMemory.
Так GC вообще никакого отношения к видеопамяти не имеет. Если, конечно, мы о .Net-овском GC.

А>>И собственно так и не дали самого важного ответа — приведите конкретный практический пример любой отрисовки ( можно в исходном коде ) где GDI будет быстрее DirectX.
А>>Все ваши попытки как-то представить белое черным как раз противоречат практике, которая подтверждает что GDI на порядок тормознее чем отрисовка через DirectX.
A>Практически любые аналитические графики.
В общем я согласен, что графикам тяжеловато на WPF. Из-за необходимости показывать большее число объектов, нужно заниматься оптимизацией. Но интересно вот что. Картинка в WPF и в GDI несколько различаются. В WPF есть сглаживание, есть субпиксельный рендеринг. Так ли аналогичен результат вывода обеих технологий, чтобы просто сравнивать время?

Здравствуйте, MxMsk, Вы писали:

A>>Медленный старт приложений крайне характерен для WPF. Причём, когда я говорю медленный, я имею ввиду десятки секунд и минуты.
MM>И все же это характерно только для первого старта. Последующие гораздо быстрее.

Ну ОС тоже не дура, кеширует. prefetch опять же.

MM>Так GC вообще никакого отношения к видеопамяти не имеет. Если, конечно, мы о .Net-овском GC.

Объекты в видеопамяти разве не привязаны к объектам GC?

MM>В общем я согласен, что графикам тяжеловато на WPF. Из-за необходимости показывать большее число объектов, нужно заниматься оптимизацией. Но интересно вот что. Картинка в WPF и в GDI несколько различаются. В WPF есть сглаживание, есть субпиксельный рендеринг. Так ли аналогичен результат вывода обеих технологий, чтобы просто сравнивать время?

Ну в GDI+ субпиксельный рендеринг и сглаживание точно есть и он полностью на CPU (в отличие от GDI). Что касается аналогичности... ну я не буду долго говорить про шрифты которые в 4.0 уже можно читать, но всё же не так всё круто как могло бы быть.

Здравствуйте, adontz, Вы писали:

MM>>Так GC вообще никакого отношения к видеопамяти не имеет. Если, конечно, мы о .Net-овском GC.
A>Объекты в видеопамяти разве не привязаны к объектам GC?
Ну не знаю. Напрямую .Net-ные объекты не вызывают методы DirectX. Кисти и тому подобные используют какие-то каналы: есть такие методы AddRefOnChannel и ReleaseRefOnChannel. Я не знаком с API DirectX, возможно тебе эти методы о чем-то говорят, но выглядит скорее, как API нативной части WPF, и фиг пойми, как она распоряжается ресурсами.

Здравствуйте, MxMsk, Вы писали:

MM>>>Так GC вообще никакого отношения к видеопамяти не имеет. Если, конечно, мы о .Net-овском GC.
A>>Объекты в видеопамяти разве не привязаны к объектам GC?
MM>Ну не знаю. Напрямую .Net-ные объекты не вызывают методы DirectX. Кисти и тому подобные используют какие-то каналы: есть такие методы AddRefOnChannel и ReleaseRefOnChannel. Я не знаком с API DirectX, возможно тебе эти методы о чем-то говорят, но выглядит скорее, как API нативной части WPF, и фиг пойми, как она распоряжается ресурсами.

Как я уже говорил, DirectX может самопроизвольно выгружать ресурсы переводя их в Lost состояние, там что-то вроде вытесняющего кеша. Это обёрнуто в СОМ (упомянутые тобой AddRef/Release), а СОМ обёрнут в .Net/GC. Аж три перпендикулярные идеологии

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

Здравствуйте, Kingofastellarwar, Вы писали:

K>Здравствуйте, MxMsk, Вы писали:

MM>>Так что получается, любой WPF контент считается трехмерной сценой.

K>ессно,и я вообще думал что наши впфники догадываются откуда растут ноги у впфных шейдеров, 3д трансформаций, способов задания 3д объектов и прочего

эээ... мужики, вы чо, издеваетесь? Я знал, что в ДиректИксе есть "чистое 2D", но то, что мелкие извращенцы вместо него заюзают 3D — я не мог и в кошмарном сне представить!!! Всё, мои возражения снимаются — WPF ещё больший сакс, чем я думал!!

(((((((

Здравствуйте, matumba, Вы писали:

M>эээ... мужики, вы чо, издеваетесь? Я знал, что в ДиректИксе есть "чистое 2D", но то, что мелкие извращенцы вместо него заюзают 3D — я не мог и в кошмарном сне представить!!! Всё, мои возражения снимаются — WPF ещё больший сакс, чем я думал!!

(((((((

Если бы ты знал как следует Direct3D, то знал бы, что там нету 2D в принципе. Так что иди поучи матчасть прежде, чем выдавать такие негодные высеры...

Здравствуйте, Kingofastellarwar, Вы писали:

K>вы вообще пиксельный или вершинный шедер хоть раз писали? попробуйте как вам говорят выше репорт нарисовать шейдерами

шейдеры это эффекты, они делают одно сложное преобразование и всё.

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

Здравствуйте, koandrew, Вы писали:

K>Здравствуйте, Kingofastellarwar, Вы писали:

K>>вы вообще пиксельный или вершинный шедер хоть раз писали? попробуйте как вам говорят выше репорт нарисовать шейдерами

шейдеры это эффекты, они делают одно сложное преобразование и всё.

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

абсолютно любой точно не получится, как минимум 2 ограничения:

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

Здравствуйте, Kingofastellarwar, Вы писали:

K>абсолютно любой точно не получится, как минимум 2 ограничения:

K>1. шейдер имеет предел длины и не он очень небольшой, точно не знаю, но наверно максимум 1к команд, потому что у гпу жесткие требования к скорости шейдров
Дык там и не нужно длинных шейдеров. В видяху гонить одномерную текстуру, например в формате UV, шейдер из неё делает геометрию/модифицирует текущую геометрию.
K>2. вершинным шейдером сложно рисовать график не по функции, а по данным, особенно если они меняются в рельном времени, например аудиоредатор, их прийдется непрерывно слать в видуху, а мы уже знаем чем это грозит
Их в любом случае придётся слать в видеокарту — неважно в виде одномерной текстуры или в виде растра...

Здравствуйте, koandrew, Вы писали:

K>Их в любом случае придётся слать в видеокарту — неважно в виде одномерной текстуры или в виде растра...

я думаю гди тут выиграет и по скорости и особенно по оперативности, потому что у него меньше накладных расходов

Здравствуйте, Kingofastellarwar, Вы писали:

K>я думаю гди тут выиграет и по скорости и особенно по оперативности, потому что у него меньше накладных расходов

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

Здравствуйте, koandrew, Вы писали:

K>Если бы ты знал как следует Direct3D, то знал бы, что там нету 2D в принципе. Так что иди поучи матчасть прежде, чем выдавать такие негодные высеры...

Ну есть Direct2D И DirectWrite

Здравствуйте, adontz, Вы писали:

A>Ну есть Direct2D И DirectWrite

Да, тока они, во-первых, есть тока в висте+, а, во-вторых, по сути не имеют к DX никакого отношения, кроме части называния

Здравствуйте, koandrew, Вы писали:

A>>Ну есть Direct2D И DirectWrite

K>Да, тока они, во-первых, есть тока в висте+, а, во-вторых, по сути не имеют к DX никакого отношения, кроме части называния

Ты плохо знаком с их внутреностями. Они оба вполне могут использовать аппаратное ускорение.

Здравствуйте, adontz, Вы писали:

A>Ты плохо знаком с их внутреностями. Они оба вполне могут использовать аппаратное ускорение.

Могут, это так. Но эти либы параллельны DirectX и никак от него не зависят. В висте же даже интерфейс видеодров поменяли под это дело...

Здравствуйте, koandrew, Вы писали:

A>>Ты плохо знаком с их внутреностями. Они оба вполне могут использовать аппаратное ускорение.
K>Могут, это так. Но эти либы параллельны DirectX и никак от него не зависят. В висте же даже интерфейс видеодров поменяли под это дело...

Ну как же паралельны

About Direct2D
Раздел High Performance with Maximum Availability. Чётко написано "Direct2D is a user-mode library that is built using the Direct3D 10.1 API". Ниже даже диаграмка есть.

Здравствуйте, adontz, Вы писали:

A>Ну как же паралельны

A>About Direct2D
A>Раздел High Performance with Maximum Availability. Чётко написано "Direct2D is a user-mode library that is built using the Direct3D 10.1 API". Ниже даже диаграмка есть.

Признаюсь, не прав, что-то меня переглючило

Здравствуйте, Kingofastellarwar, Вы писали:

K>так вот я ОЧЕНЬ сомневаюсь что ВПФники такие крутые пацаны что смогли на такую сложную структуру впф приложения натянуть технологии упаковки, ибо мне это видится катастофический сложностью, потому что в 3д движках перерисовывается всегда весь экран и есть возможность собрать и подготовить данные.

Добавлю еще.

На DX10.1 перенастройка D3DDevice(например втыкание нового шейдера, и прочее конфигурирование), и вызов Draw может занимать до 0.1 милисекунды, причем от мощи видеокарты это не должно зависеть. Чтобы не потерять 60fps, 16.7 ms на кадр, получается нельзя вызывать Draw(с перенастройкой Device) более 100 раз за кадр. И то там времени останется меньше половины чтобы прорисоваться и Present сделать.

Кроме того в UI есть проблема в том, что может быть очень большая куча мелких контролов и для каждого может быть нужен отдельный clip — отсечение по прямоугольнику. А также индивидуальные трансформацими в каждом контрольчике.
В DX, апаратное отсечение, как таковое, возможно только по одному прямоугольнику — на одну операцию Draw. Прийдется считать обрезания на процессоре.

Насколько я понял по тестам в D2D комбинируют аппаратные обрезания и программные, потому что если Clip(Scissor) менять редко(для больших блоков) то быстродействие не просаживается. Если менять после каждого примитива, то просаживается но совсем чуть чуть — сделано эффективно. Т.е. несколько тысяч изменений ClipRectangle в D2D не проблема — ясно что при чакстых сменах уже не аппаратная обрезалка.
Обрезание вроде мелочь, а без него GUI не сделаешь.

ИМХО, у WPF такая низкая производительность даже не из-за большого количества Draw на кадр. А потому что на стороне процессора много работы делают, и неэффективно. Даже 10тыс мелких прямоугольничков нарисовать проблема. Чтобы нарисовать рамку прямоугольника в универсальном формате — треугольниками с плавающей точкой.
Это ведь надо 8 треугольников. Их через смежности указывать нельзя, получается 24 float числа, на один прямоугольник. Если потом эти 24 числа обрезать и трансформировать(умножать на матрицы) на стороне процессора, то получится нынешняя производительность WPF.

Может в WPF и не все матрицы проц умножает, но в GUI теоретически могут быть на один экран сотни разных матриц.
Как это аппаратно сделать для каждого контрола, на один Draw? В константный буффер загнать массив матриц, а вертексам приписывать индексы матриц? Такое наверно медленно будет работать, да и константные буферы не резиновые.

	От:	evo
	Дата:	28.04.11 12:19
	Оценка:

	От:	vmpire
	Дата:	28.04.11 13:06
	Оценка:

	От:	evo
	Дата:	28.04.11 13:17
	Оценка:

От:	henson	http://www.njt-rails.com
Дата:	28.04.11 13:32
Оценка:

	От:	vmpire
	Дата:	28.04.11 14:10
	Оценка:

От:	MozgC	http://nightcoder.livejournal.com
Дата:	28.04.11 14:43
Оценка:	21 (6)

От:	adontz	http://adontz.wordpress.com/
Дата:	29.04.11 12:02
Оценка:	+1 -4

	От:	Воронков Василий
	Дата:	30.04.11 06:28
	Оценка:	1 (1) +1

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	03.05.11 07:45
Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	04.05.11 09:11
Оценка:

	От:	Kingofastellarwar
	Дата:	04.05.11 11:39
	Оценка:	57 (2) +2

От:	koandrew	http://thingselectronic.blogspot.ca/
Дата:	25.05.11 17:06
Оценка: