Всем привет!
Как теперича обстоят дела с "шустростью" GUI деланного на .Net ?
Помню году в 2002-2003 ради интереса сделал простенькую штуку: датасет заполнялся из БД (т.е. данные становились in-memory) и биндился к гриду лежащему на форме. Так как это все работало — при скролинге в гриде было глазом отчетливо заметно как перерисывывается КАЖДАЯ СТРОКА И ЯЧЕЙКА грида !!! (машинка по тем временам была неплохая что-то под (1Гигагерц, памяти 512мб) , а при скролинге при нажатой клавише "вниз", можно было смотреть мультик — надо ли говорить что при такой скорости GUI не могло быть и речи о переводе разработки наших приложений под платформу .Net .
Уважаемые коллеги, просто хотел поинтересоваться как теперь-то дела? Все также тормозит дата-GUI или пользователи уже могут работать не плюясь ...

Спасибо за внимание.

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

P>Как теперича обстоят дела с "шустростью" GUI деланного на .Net ?
шустрости хватает

P>Помню году в 2002-2003
как и в 2002-м году

P>ради интереса сделал простенькую штуку: датасет заполнялся из БД (т.е. данные становились in-memory) и биндился к гриду лежащему на форме.
и сколько вы туда залили?

P>Так как это все работало — при скролинге в гриде было глазом отчетливо заметно как перерисывывается КАЖДАЯ СТРОКА И ЯЧЕЙКА грида !!! (машинка по тем временам была неплохая что-то под (1Гигагерц, памяти 512мб) , а при скролинге при нажатой клавише "вниз", можно было смотреть мультик
вообще говоря, DataGrid никогда не являлся мерилом (и образцом) производительности .NET в целом и WinForms в частности. Он действительно достаточно плохо работает с БОЛЬШИМ количеством данных (вот только зачем заливать клиенту пару десятков мегабайт данных — это очень большой вопрос), но что бы заставить даже его работать в режиме слайд-шоу надо действительно МНОГО данных ему скормить. Тут накладывается много факторов, во-первых он отрисовывается через GDI+ (тот же GDI много шустрее), он работает в невиртуальном режиме, кривые руки писавших его программистов. Но в любом случае на основе одного контрола делать вывод о всей платформе — крайне странно

P>- надо ли говорить что при такой скорости GUI не могло быть и речи о переводе разработки наших приложений под платформу .Net .
не надо так говорить

P> Уважаемые коллеги, просто хотел поинтересоваться как теперь-то дела? Все также тормозит дата-GUI или пользователи уже могут работать не плюясь ...
все также все ок. Но если клиенты сидят на PII, 64Мб, то тогда .NET спорное решение (хотя работать конечно будет, или например вполне можно посмотреть на ASP.NET).

P>Спасибо за внимание.
всегда пожалуйста. И в заключение, как пример (и как источник информации о работе с .NET) можно посмотреть на местный проект Janus. Если почитать форум этого проекта, то можно нарыть много о тормозах Janus (когда база переростает 200-300 Мб), а значит (многие как раз делали такой вывод) тормозит .NET. Но вывод такой неверен, как раз в указанном случае .NET код летал, тормозил вполне себе unmanaged Access. Как только привинтили возможность работать с MS-SQL, у меня полуторагигабайтная база залетала (хотя и раньше Access вполне себе работал, но хуже ).
Это все к тому, что не надо делать поспешных выводов.

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

P>Как теперича обстоят дела с "шустростью" GUI деланного на .Net ?
Примерно так же как и раньше. Пользую DevExpress, при таскании docking panes, скроллинге грида и т.д. и т.п процессор на 3 ГГц машине может быть загружен на 80-100%. Тот же функционал реализованный с использованием нативных библиотек загружает процессор на какие-то жалкие 2-5%. Но на 3 ГГц торможение .Net GUI уже не ощущается субъективно (если процессор не загружен чем-либо ещё).

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

P>Всем привет!
P>Как теперича обстоят дела с "шустростью" GUI деланного на .Net ?
Да не лучше обстоят. В дизайнере делаешь пустую форму, кидаешь на неё тулбар в несколько кнопок, статус, тривью слева дочишь, сплиттер, листвью справа, докинг = фулл. При ресайзе моргает, видно как сначала вылезает край формы а потом его пытается догонять контрол... но не может, пока ресайз не закончишь. И это без данных, пустые контролы. Ужасть вопсчем. У меня XP SP2, 256 метров, Celeron 2000...

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


P>>ради интереса сделал простенькую штуку: датасет заполнялся из БД (т.е. данные становились in-memory) и биндился к гриду лежащему на форме.
SAV>и сколько вы туда залили?

пару сотен записей


SAV>вообще говоря, DataGrid никогда не являлся мерилом (и образцом) производительности .NET в целом и WinForms в частности. Он действительно достаточно плохо работает с БОЛЬШИМ количеством данных (вот только зачем заливать клиенту пару десятков мегабайт данных — это очень большой вопрос), но что бы заставить даже его работать в режиме слайд-шоу надо действительно МНОГО данных ему скормить. Тут накладывается много факторов, во-первых он отрисовывается через GDI+ (тот же GDI много шустрее), он работает в невиртуальном режиме, кривые руки писавших его программистов. Но в любом случае на основе одного контрола делать вывод о всей платформе — крайне странно

Вообщем, да, но так как у нас в основном бизнес-приложения работающие (ввод и обработка) с данными (тетеньки вклачивают данные и рассматривают), то качество поставляемых в комплекте с .Net GUI (DataGrid) было очень актуально.
А можноли попростому заставить DataGrid отрисовываться не через GDI+ ?
А так конечно же печально, что базовый контрол для дата-GUI "не являлся мерилом (и образцом) производительности", это фактически означает что опять надо что-то выдумывать (искать достойную, альтернативу, писать свой — брр)...


P>> Уважаемые коллеги, просто хотел поинтересоваться как теперь-то дела? Все также тормозит дата-GUI или пользователи уже могут работать не плюясь ...
SAV>все также все ок. Но если клиенты сидят на PII, 64Мб, то тогда .NET спорное решение (хотя работать конечно будет, или например вполне можно посмотреть на ASP.NET).

А если PII, 512М ? Т.е. свопа нет, но хватит ли гигагерцов чтоб подтормаживания интерфейса не было (для упрощения считаем что на уровне данных все — ОК, вопрос именно об GUI и DataGrid в частности) ?

Интересно кто-нить использует .Net приложения на немощных рабочих станциях (PII, 256М — памяти теперь легко докупить , а вот замена проца и материнки да еще в масштабах предприятия — сложнее) поделитесь плиз впечатлениями об "шустрости"/"нешустрости" GUI...

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

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

P>>Как теперича обстоят дела с "шустростью" GUI деланного на .Net ?
А>Да не лучше обстоят. В дизайнере делаешь пустую форму, кидаешь на неё тулбар в несколько кнопок, статус, тривью слева дочишь, сплиттер, листвью справа, докинг = фулл. При ресайзе моргает, видно как сначала вылезает край формы а потом его пытается догонять контрол... но не может, пока ресайз не закончишь. И это без данных, пустые контролы. Ужасть вопсчем. У меня XP SP2, 256 метров, Celeron 2000...

Ээээ..., это точно ужасть, хмм... интересно почему так, особенно если принять во внимание что вроде бы как "внизу" (по данным разных тестов и местных тестов "шустриков" в частности) все вроде бы хорошо, а при работе реальных библиотек (GUI-контролов в частности ) все так эээ... подтормаживает. Особенно если сравнить с GUI деланном на Delphi — там просто песня а не скорость... эх.

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

P>Вообщем, да, но так как у нас в основном бизнес-приложения работающие (ввод и обработка) с данными (тетеньки вклачивают данные и рассматривают), то качество поставляемых в комплекте с .Net GUI (DataGrid) было очень актуально.
Попробуйте посмотреть в сторону .NET, там вводили новые контролы для работы с табличными данными. Сам с ними подробно не работал, но по слухам они получше.

P>А можноли попростому заставить DataGrid отрисовываться не через GDI+ ?
нет, тут начинали было писать свой grid, но не закончили. Я и сам в нем начинал учавствовать, но потом необходимость в нем для меня отпала в связи с новой работой и тотальным отсутствием времени Кстати там уже была достаточно шустрая версия, правда единственное что она могла это отрисовывать и скролить большое количество строк

P>А так конечно же печально, что базовый контрол для дата-GUI "не являлся мерилом (и образцом) производительности", это фактически означает что опять надо что-то выдумывать (искать достойную, альтернативу, писать свой — брр)...
да, в свое время с достойными и бесплатными grid`ами была проблема. Сейчас может быть ситуация и изменилась, но я, честно говоря, сомневаюсь. Но вообще говоря, шустрости стандартного DataGrid (здесь имеется в виду .NET 1.1) для тех же нескольких сотен записей вполне достаточно (меня искренне удивляет, что он у вас тормозил на таком количестве). И с ним вполне можно работать после определенной обработки напильником. Основная его проблема это невозможность заставить его работать в виртуальном режиме (там в коде один умник написал неотключаемый перебор всех строк на предмет наличия ошибок ). В том же GridView из .NET 2 такое уже возможно (я вроде бы делал когда где-то год назад игрался с ним еще на первой бете, с тех пор я с этими контролами не работал, так что актуальность этой информации не фонтан )

P>А если PII, 512М ? Т.е. свопа нет, но хватит ли гигагерцов чтоб подтормаживания интерфейса не было (для упрощения считаем что на уровне данных все — ОК, вопрос именно об GUI и DataGrid в частности) ?
если использовать простые контролы, то должно хватить (те же DevExpress достаточно тяжелые, но мощные вещи)

P>Интересно кто-нить использует .Net приложения на немощных рабочих станциях (PII, 256М — памяти теперь легко докупить , а вот замена проца и материнки да еще в масштабах предприятия — сложнее) поделитесь плиз впечатлениями об "шустрости"/"нешустрости" GUI...
в принципе можно, но надо тестировать.

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

P>Ээээ..., это точно ужасть, хмм... интересно почему так, особенно если принять во внимание что вроде бы как "внизу" (по данным разных тестов и местных тестов "шустриков" в частности) все вроде бы хорошо, а при работе реальных библиотек (GUI-контролов в частности ) все так эээ... подтормаживает. Особенно если сравнить с GUI деланном на Delphi — там просто песня а не скорость... эх.

Две возможные причины из бесконечного множества таковых:
1) низкая производительность GDI+
2) типичные реализации кода что-нибудь рисующего создают н-ное кол-во объектов и при перерисовке такой код может выполняться довольно часто, а создание объектов (и сбор мусора) в .Net — дело (крайне) медленное.

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

P>Ээээ..., это точно ужасть, хмм... интересно почему так, особенно если принять во внимание что вроде бы как "внизу" (по данным разных тестов и местных тестов "шустриков" в частности) все вроде бы хорошо, а при работе реальных библиотек (GUI-контролов в частности ) все так эээ... подтормаживает. Особенно если сравнить с GUI деланном на Delphi — там просто песня а не скорость... эх.

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

А>Чёрт ево знает почему я решил вести разработку на стандартных и посадить пару чувачков писать свои, постепенно подменяя. Надеюсь в итоге всё получится хорошо... Если аккуратно писать и всё такое.

А это глючное кривое тормознутое убожество DataGrid из первого фреймворка я использовать вообще не буду. Поставлю для начала листвью заместо него. Что можно сказать о контроле, где даже получение выделенного элемента является нетривиальной задачей, требующей недюжего воображения и чтения факов на готдотнете ??

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

А>Да не лучше обстоят. В дизайнере делаешь пустую форму, кидаешь на неё тулбар в несколько кнопок, статус, тривью слева дочишь, сплиттер, листвью справа, докинг = фулл. При ресайзе моргает, видно как сначала вылезает край формы а потом его пытается догонять контрол...

Да, есть такое, но это скорее кривизна реализации конкретных контролов, а не платформы в целом. Просто где-то отрисовка вызывается лишний раз, чем надо.

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

А>256 метров, Celeron 2000

У меня абсолютно аналогичная конфигурация, ноутбук правда

P>>Как теперича обстоят дела с "шустростью" GUI деланного на .Net ?
А>Да не лучше обстоят. В дизайнере делаешь пустую форму, кидаешь на неё тулбар в несколько кнопок, статус, тривью слева дочишь, сплиттер, листвью справа, докинг = фулл. При ресайзе моргает, видно как сначала вылезает край формы а потом его пытается догонять контрол... но не может, пока ресайз не закончишь. И это без данных, пустые контролы. Ужасть вопсчем. У меня XP SP2, 256 метров, Celeron 2000...

Эх... и после этого наежают на Java/Swing — да он ничем не хуже (просто мурашки свои)

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

А>Да, есть такое, но это скорее кривизна реализации конкретных контролов, а не платформы в целом. Просто где-то отрисовка вызывается лишний раз, чем надо.
Дат там похоже не один раз..

А>Конечно неприятно это, но что делать, нет в жизни счастья. С другой стороны, по моему скромному опыту, реализовывать всё это самому (авто-ресайз, цвета, шрифты и пр) на MFC например, заняло бы ещё больше времени.
По опыту, команда из 3х человек за 1 год. Классный data-bound/unbound grid с кучей настроек (и цвета и шрифты и колонки разные добавлять, иконки там, галочки... только XP стиль не умел). Летал на полумиллионе записей (cel 1700 256mb) как нортон коммандер на PII-300. При этом был сделан на тормознутейшем VB6. Я честно не знаю, как на нормальном вроде C# надо извратнуться чтоб так всё работало, даже если GDI+ на порядок медленнее GDI...

А>>256 метров, Celeron 2000

А>У меня абсолютно аналогичная конфигурация, ноутбук правда

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

А>По опыту, команда из 3х человек за 1 год. Классный data-bound/unbound grid с кучей настроек (и цвета и шрифты и колонки разные добавлять, иконки там, галочки... только XP стиль не умел).

Я гридами не интересовался, что навскидку удалось найти в поиске, среди сторонних контролов:
http://www.grid2000.com
http://www.componentsource.com/Catalog.asp?fl=C203&sc=CS&bc=C100~C203&cv=&ul=en&SERC=GGC1&bhcp=1
http://www.devage.com/SourceGrid/SourceGrid2_EN.html
Среди них есть и платные и бесплатные, правда насколько хорошо оно работает, фиг знает...

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

P>Ээээ..., это точно ужасть, хмм... интересно почему так, особенно если принять во внимание что вроде бы как "внизу" (по данным разных тестов и местных тестов "шустриков" в частности) все вроде бы хорошо, а при работе реальных библиотек (GUI-контролов в частности ) все так эээ... подтормаживает.
Политика партии. MS не хочет отнимать хлеб у сторонних разработчиков контролов, поэтому свои пишет просто чтобы хоть как-то работали, но занимая голову лишним тюнингом.

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

M>Политика партии. MS не хочет отнимать хлеб у сторонних разработчиков контролов, поэтому свои пишет просто чтобы хоть как-то работали, но занимая голову лишним тюнингом.
Особенно PropertyGrid

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

M>Политика партии. MS не хочет отнимать хлеб у сторонних разработчиков контролов, поэтому свои пишет просто чтобы хоть как-то работали, но занимая голову лишним тюнингом.

Хм... наврядли, ведь GUI этож "лицо" платформы, это скокож народ спугнет, хотя все равно придут конечно потом, наверно ближе к правде — ресурсы на разработку GUI были сильно урезаны (сроки поджимали, деньги пустили в маркетинг и т.п., надежда что будущие увеличение гигагерцев все компенсирует — отчасти оно и так).
А может все-таки при увеличении сложности кода каке-нибудь все таки возникают объективные проблемы с производительностью? уж как-то неверится что на "лицо" платформы MS денег зажали...

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


А>А это глючное кривое тормознутое убожество DataGrid из первого фреймворка я использовать вообще не буду.

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

Как-то грустно все это... Сейчас существует два клиент-серверных проекта, написанных на Delphi 6. В свете последних событий было желание переписать все под .NET 2.0. Благо Micrsoft и IDE бесплатно выложил. Но почитав этот топик начали меня терзать смутные сомнения. У большинства клиентов стоят слабые машины до 1 ГГц. Так что ж, GUI будет сильно тормозить? Это однозначное мнение всех присутсвующих или все таки есть надежда?

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

P>Хм... наврядли, ведь GUI этож "лицо" платформы, это скокож народ спугнет,
Ну не спугнуло ведь, зато контор разрабатывающих контролы в замен MS-овских — сотни, а это серьезно увеличивает продажи студии.

P>А может все-таки при увеличении сложности кода каке-нибудь все таки возникают объективные проблемы с производительностью?
Ну уж не в гридах точно, есть код который существенно сложнее и тем не менее летает как трофейный мессершмит... Там по коду видно, что гриды писались в аутсорсии, очевидно из-за этого и проблемы.

P> уж как-то неверится что на "лицо" платформы MS денег зажали...
Тем не менее, факт. Вплоть до того, что каждая из команд внутри самого MS предпочитает написать свой собственный грид, если им надо, а не пользуется стандартным, это к тому, что нормальные гриды у них есть...
Кстати во 2-м FW они должны были это дело полностью переписать по человечески, вплоть до несовместимости со старым. Грид я еще не смотрел, но над другими контролами они основательно надругались.