Здравствуйте, Qbit86, Вы писали:
Q>Причём здесь создаются тяжеловесные Shape'ы, а можно рисовать более низкоуровневые freeze'анутые StreamGeometry, например.
Согласен. Роботает довольно быстро. Но..
1. Все равно медленне чем WinForms
2. Попробуй для эксперимента используя VirtualCanvas размещать на экране сразу 100 элементов. Для Excel это только линии сетки.
Если же отрисовывать еще границы ячеек разной толщины и цвета + использовать разнообразную заливку ячеек + еще успевать рисовать текст. То получается около 1000 эелементов.
RT>>Да и на несколько порядков дешевле заплатить 100-200К рублей за разработку, чем покупать 10k лиценнзий даже с 50% скидкой. G>100-200 тыр за разработку хватит чтобы покрыть 0.001% функциональности excel. Пользователям обычно нужно побольше.
G>Есличе — сам сталкивался с таким проектом. Чем дальше писали, тем больше становилось понятно что пользователям нужен именно excel. G>В итоге для нескольких отделов таки написали расширения excel, так они нарадоваться не могли.
G>Естественно сумма разработки многократно превысила сумму покупки лицензий на офис на всю организацию. И кстати офис у многих уже стоял.
Ситуация складывалась аналогично. В итоге получили облегченный Excel (графики, формулы, автофильтры, привязка к различным источникам данных,печать, эспорт в Excel ).
Все это обошлось в 2 мульена. Пользователи довольный, + получили полность лицензионно чистый продукт.
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, gandjustas, Вы писали:
RT>>>Да и на несколько порядков дешевле заплатить 100-200К рублей за разработку, чем покупать 10k лиценнзий даже с 50% скидкой. G>>100-200 тыр за разработку хватит чтобы покрыть 0.001% функциональности excel. Пользователям обычно нужно побольше.
G>>Есличе — сам сталкивался с таким проектом. Чем дальше писали, тем больше становилось понятно что пользователям нужен именно excel. G>>В итоге для нескольких отделов таки написали расширения excel, так они нарадоваться не могли.
G>>Естественно сумма разработки многократно превысила сумму покупки лицензий на офис на всю организацию. И кстати офис у многих уже стоял.
RT>Ситуация складывалась аналогично. В итоге получили облегченный Excel (графики, формулы, автофильтры, привязка к различным источникам данных,печать, эспорт в Excel ). RT>Все это обошлось в 2 мульена. Пользователи довольный, + получили полность лицензионно чистый продукт.
То есть таки excel на рабочих машинах стоял... А можно было гораздо меньшими проблемами в UI обойтись взяв excel изначально.
Здравствуйте, RadmirT, Вы писали:
Q>>Причём здесь создаются тяжеловесные Shape'ы, а можно рисовать более низкоуровневые freeze'анутые StreamGeometry, например. RT>Согласен. Роботает довольно быстро. Но.. RT>1. Все равно медленне чем WinForms
Посмотри ещё код к статье Петцотльда «Writing More Efficient ItemsControls». Там он рисует DrawingVisual'ами. Я так понимаю, эти пепяки довольно быстро попадают в неуправляемую часть WPF, тесно взаимодействующую с DirectX, минуя богомерский GDI.
Здравствуйте, gandjustas, Вы писали:
G>То есть таки excel на рабочих машинах стоял... А можно было гораздо меньшими проблемами в UI обойтись взяв excel изначально.
Excel стоял но на очень ограниченном количестве рабочих мест около 500. На остальных рабочих станциях либо ничего не стояло либо стоял ОpenОffice.
Здравствуйте, Qbit86, Вы писали:
Q>Посмотри ещё код к статье Петцотльда «Writing More Efficient ItemsControls». Там он рисует DrawingVisual'ами. Я так понимаю, эти пепяки довольно быстро попадают в неуправляемую часть WPF, тесно взаимодействующую с DirectX, минуя богомерский GDI.
ИМХО если мы рисуем все ручками с помошью Drawing нафига нам вообще нужен WPF. генрим в памяти bmp а потом ввыводим его на экран.
Здравствуйте, RadmirT, Вы писали:
Q>>Посмотри ещё код к статье Петцотльда «Writing More Efficient ItemsControls». Там он рисует DrawingVisual'ами. Я так понимаю, эти пепяки довольно быстро попадают в неуправляемую часть WPF, тесно взаимодействующую с DirectX, минуя богомерский GDI.
RT>ИМХО если мы рисуем все ручками с помошью Drawing нафига нам вообще нужен WPF. генрим в памяти bmp а потом ввыводим его на экран.
Рисование в DrawingContext'е является отложенным (retaining), команды накапливаются, к ним можно применять разные трансформации, плюс уже на уровне DrawingVisual'ов формируется визуальное дерево, по нему можно ходить, осуществлять hit testing, etc.
Здравствуйте, Qbit86, Вы писали:
Q>Рисование в DrawingContext'е является отложенным (retaining), команды накапливаются, к ним можно применять разные трансформации, плюс уже на уровне DrawingVisual'ов формируется визуальное дерево, по нему можно ходить, осуществлять hit testing, etc.
Это понятно. Но все это относительно легко делатся в WinForms. Пропадает самое главное — возможность использоваяния "красявости" WPF.
Здравствуйте, RadmirT, Вы писали:
Q>>Рисование в DrawingContext'е является отложенным (retaining), команды накапливаются, к ним можно применять разные трансформации, плюс уже на уровне DrawingVisual'ов формируется визуальное дерево, по нему можно ходить, осуществлять hit testing, etc.
RT>Это понятно. Но все это относительно легко делатся в WinForms. Пропадает самое главное — возможность использоваяния "красявости" WPF.
Э-э... Куда пропадает? Был разговор за примитивы, а не за «красявости». Для каждой задачи выбирается соответствующий уровень API.
Здравствуйте, Qbit86, Вы писали:
Q>Э-э... Куда пропадает? Был разговор за примитивы, а не за «красявости». Для каждой задачи выбирается соответствующий уровень API.
Примтивы я могу рисовать и в WinForms при том быстрее чем в WPF. Тогда возникает вопрос, а зачем мне нужен в данном случаее WPF, какие он мне дает приимущества по сравненю с использованием GDI/GDI+?
Здравствуйте, RadmirT, Вы писали:
Q>>Э-э... Куда пропадает? Был разговор за примитивы, а не за «красявости». Для каждой задачи выбирается соответствующий уровень API.
RT>Примтивы я могу рисовать и в WinForms при том быстрее чем в WPF. Тогда возникает вопрос, а зачем мне нужен в данном случаее WPF, какие он мне дает приимущества по сравненю с использованием GDI/GDI+?
Насчёт в «GDI+ быстрее, чем в DirectX» у меня есть большие сомнения. Примеры ведь в этой ветке были только с моей стороны.
Здравствуйте, RadmirT, Вы писали:
RT>Примтивы я могу рисовать и в WinForms при том быстрее чем в WPF. Тогда возникает вопрос, а зачем мне нужен в данном случаее WPF, какие он мне дает приимущества по сравненю с использованием GDI/GDI+?
Ну, если сравнивать только рисование прямоугольников, то может и нет никаких преимуществ
Здравствуйте, Qbit86, Вы писали:
Q>Насчёт в «GDI+ быстрее, чем в DirectX» у меня есть большие сомнения. Примеры ведь в этой ветке были только с моей стороны.
Я не утверждаю что "GDI+ быстрее, чем в DirectX" сли бы это было бы так, то DirectX никому не был бы нужен.
Я говорю что в конкретном случае, когда необходимо оперироват большим количеством примитивов,которые постоянно удаляются/добавляются, использования WinForms + GDI+ эффективнее чем WPF + DirectX
Здравствуйте, RadmirT, Вы писали:
RT>А что еше нужно элементу управления который отображает таблицу а ля Excel, и которому не нужны анимация, эффект aero, 3D и прочие няшки?
А что, все программы в мире только и делают, что используют "элемент управления который отображает таблицу а ля Excel"? Этим же WPF не ограничивается. К чему этот стеб про "няшки"? Я никоим образом не имел ввиду ни анимацию, ни aero, ни 3D. Главным образом WPF — это грамотный компоновщик и привязка данных. И потом, если не заметил, то я подтвердил
, что при большом количестве примитивов есть тормоза. Но эту проблему можно попробовать решить частичным рисованием: в области, большей чем видимая, но меньшей, чем огромный компонент.
Здравствуйте, Jack128, Вы писали:
J>Здравствуйте, MxMsk, Вы писали:
MM>>У меня в решении этой задачи вообще нет кода. А у тебя?
J>О. Очень частое заявление от WPF'ников. Отсюда вопрос: J>а вы xaml за код не считаете ?? Его не нужно писать, не нужно поддерживать??
Это был троллинг В той задаче XAML простой получается по сравнению с тем, что придется ваять в GDI+. Поддержка его не составит труда.
Здравствуйте, MxMsk, Вы писали: MM>А что, все программы в мире только и делают, что используют "элемент управления который отображает таблицу а ля Excel"? Этим же WPF не ограничивается. К чему этот стеб про "няшки"? Я никоим образом не имел ввиду ни анимацию, ни aero, ни 3D. Главным образом WPF — это грамотный компоновщик и привязка данных. И потом, если не заметил, то я подтвердил
, что при большом количестве примитивов есть тормоза. Но эту проблему можно попробовать решить частичным рисованием: в области, большей чем видимая, но меньшей, чем огромный компонент.
Так я ни не говорю что WPF плох. Я просто пытаюсь донести что ненадо разимахивая флагом все проекты делать на WPF. Есть целая куча задач, решение которых на WinForms проше и эффективнее чем решение аналогичной задачи на WPF.
Здравствуйте, RadmirT, Вы писали: RT>Так я ни не говорю что WPF плох. Я просто пытаюсь донести что ненадо разимахивая флагом все проекты делать на WPF. Есть целая куча задач, решение которых на WinForms проше и эффективнее чем решение аналогичной задачи на WPF.
Примеры в студию. Будем, так сказать, отталкиваться от реальности.
В той задаче XAML простой получается по сравнению с тем, что придется ваять в GDI+. Поддержка его не составит труда.
