Господа, сталкивался ли кто-нибудь у DevExpress.GridControl с тем, что когда в нем находится например 1 тысяча записей, около 7 колонок с текстовой информацией, то при скролировании наблюдаются некоторые тормоза. Я затрудняюсь правильно объяснить, но... Короче ощущение такое, что скролирование идет не в real-time режиме, а с каким-то запозданием. Т.е. схватил скролер, потянул вниз, грид информацию начал прокручивать, но как-то рывками, чуть-чуть с запозданием и т.п.

Как с этим можно бороться? Тоже самое в ихних же демках наблюдается.

PS
Речь идет о версии 6.2, включена поддержка скина, который используется по-умолчанию.

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Господа, сталкивался ли кто-нибудь у DevExpress.GridControl с тем, что когда в нем находится например 1 тысяча записей, около 7 колонок с текстовой информацией, то при скролировании наблюдаются некоторые тормоза. Я затрудняюсь правильно объяснить, но... Короче ощущение такое, что скролирование идет не в real-time режиме, а с каким-то запозданием. Т.е. схватил скролер, потянул вниз, грид информацию начал прокручивать, но как-то рывками, чуть-чуть с запозданием и т.п.

ЩЕ>Как с этим можно бороться? Тоже самое в ихних же демках наблюдается.

ЩЕ>PS
ЩЕ>Речь идет о версии 6.2, включена поддержка скина, который используется по-умолчанию.

UP

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Господа, сталкивался ли кто-нибудь у DevExpress.GridControl с тем, что когда в нем находится например 1 тысяча записей, около 7 колонок с текстовой информацией, то при скролировании наблюдаются некоторые тормоза. Я затрудняюсь правильно объяснить, но... Короче ощущение такое, что скролирование идет не в real-time режиме, а с каким-то запозданием. Т.е. схватил скролер, потянул вниз, грид информацию начал прокручивать, но как-то рывками, чуть-чуть с запозданием и т.п.

ЩЕ>Как с этим можно бороться? Тоже самое в ихних же демках наблюдается.

ЩЕ>PS
ЩЕ>Речь идет о версии 6.2, включена поддержка скина, который используется по-умолчанию.
Да, есть такое дело. Только в гриде это еще ничего, вот в TreeList'е вообще хана — там тормозит скроллер. Я пытался оптимизировать это дело, долго копался в исходниках и понял, что у них там написано всё через одно место. Так что либо пинать суппорт, либо просто смериться.

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

МЗ>Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>>Господа, сталкивался ли кто-нибудь у DevExpress.GridControl с тем, что когда в нем находится например 1 тысяча записей, около 7 колонок с текстовой информацией, то при скролировании наблюдаются некоторые тормоза. Я затрудняюсь правильно объяснить, но... Короче ощущение такое, что скролирование идет не в real-time режиме, а с каким-то запозданием. Т.е. схватил скролер, потянул вниз, грид информацию начал прокручивать, но как-то рывками, чуть-чуть с запозданием и т.п.

ЩЕ>>Как с этим можно бороться? Тоже самое в ихних же демках наблюдается.

ЩЕ>>PS
ЩЕ>>Речь идет о версии 6.2, включена поддержка скина, который используется по-умолчанию.
МЗ>Да, есть такое дело. Только в гриде это еще ничего, вот в TreeList'е вообще хана — там тормозит скроллер. Я пытался оптимизировать это дело, долго копался в исходниках и понял, что у них там написано всё через одно место. Так что либо пинать суппорт, либо просто смериться.

Причем замечено, что особенно тормоза проявляются, если окно развернуто в максимизированном виде, т.е. грид или трилист занимает всю площадь окна. И ведь такие замечательные компоненты и по возможностям и по своей объектной модели и по интеграции их дизайнеров в VS.... но тормоза при скролинге... Я тут слышал не раз, что есть люди которые успешно используют DevExpress компоненты. Может вы поделитесь. как решали проблемы скролинга?

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Здравствуйте, Максим Зелинский, Вы писали:

МЗ>>Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>>>Господа, сталкивался ли кто-нибудь у DevExpress.GridControl с тем, что когда в нем находится например 1 тысяча записей, около 7 колонок с текстовой информацией, то при скролировании наблюдаются некоторые тормоза. Я затрудняюсь правильно объяснить, но... Короче ощущение такое, что скролирование идет не в real-time режиме, а с каким-то запозданием. Т.е. схватил скролер, потянул вниз, грид информацию начал прокручивать, но как-то рывками, чуть-чуть с запозданием и т.п.

ЩЕ>>>Как с этим можно бороться? Тоже самое в ихних же демках наблюдается.

ЩЕ>>>PS
ЩЕ>>>Речь идет о версии 6.2, включена поддержка скина, который используется по-умолчанию.
МЗ>>Да, есть такое дело. Только в гриде это еще ничего, вот в TreeList'е вообще хана — там тормозит скроллер. Я пытался оптимизировать это дело, долго копался в исходниках и понял, что у них там написано всё через одно место. Так что либо пинать суппорт, либо просто смериться.

ЩЕ>Причем замечено, что особенно тормоза проявляются, если окно развернуто в максимизированном виде, т.е. грид или трилист занимает всю площадь окна. И ведь такие замечательные компоненты и по возможностям и по своей объектной модели и по интеграции их дизайнеров в VS.... но тормоза при скролинге... Я тут слышал не раз, что есть люди которые успешно используют DevExpress компоненты. Может вы поделитесь. как решали проблемы скролинга?
Просто мерились с этим и писали в суппорт, чтобы разработчики ускорили отрисовку. С TreeList'ом они что-то сделали, стал где-то в половину быстрее. Я две недели занимался этим вопросом в отношении TreeList'а и отметил, что в этом компоненте очень неэффективна реализована отрисовка: все расчеты размеров происходят каждый раз при отрисовке, независимо, изменилось что либо или нет. Закэшировав эти результаты у меня получился прирост где то в два раза, но зато начал немного глючить отрисовщик, так как я не смог добраться до методов именно расчета, кэшировал более высокоуровневые классы.
Есть конечно выход купить сорс код и самому перелопачить там всё, но на это нет времени, а подтормажевание отрисовки наших юзеров не сильно волнуют.

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

МЗ>Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>>Здравствуйте, Максим Зелинский, Вы писали:

МЗ>>>Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>>>>Господа, сталкивался ли кто-нибудь у DevExpress.GridControl с тем, что когда в нем находится например 1 тысяча записей, около 7 колонок с текстовой информацией, то при скролировании наблюдаются некоторые тормоза. Я затрудняюсь правильно объяснить, но... Короче ощущение такое, что скролирование идет не в real-time режиме, а с каким-то запозданием. Т.е. схватил скролер, потянул вниз, грид информацию начал прокручивать, но как-то рывками, чуть-чуть с запозданием и т.п.

ЩЕ>>>>Как с этим можно бороться? Тоже самое в ихних же демках наблюдается.

ЩЕ>>>>PS
ЩЕ>>>>Речь идет о версии 6.2, включена поддержка скина, который используется по-умолчанию.
МЗ>>>Да, есть такое дело. Только в гриде это еще ничего, вот в TreeList'е вообще хана — там тормозит скроллер. Я пытался оптимизировать это дело, долго копался в исходниках и понял, что у них там написано всё через одно место. Так что либо пинать суппорт, либо просто смериться.

ЩЕ>>Причем замечено, что особенно тормоза проявляются, если окно развернуто в максимизированном виде, т.е. грид или трилист занимает всю площадь окна. И ведь такие замечательные компоненты и по возможностям и по своей объектной модели и по интеграции их дизайнеров в VS.... но тормоза при скролинге... Я тут слышал не раз, что есть люди которые успешно используют DevExpress компоненты. Может вы поделитесь. как решали проблемы скролинга?
МЗ>Просто мерились с этим и писали в суппорт, чтобы разработчики ускорили отрисовку. С TreeList'ом они что-то сделали, стал где-то в половину быстрее. Я две недели занимался этим вопросом в отношении TreeList'а и отметил, что в этом компоненте очень неэффективна реализована отрисовка: все расчеты размеров происходят каждый раз при отрисовке, независимо, изменилось что либо или нет. Закэшировав эти результаты у меня получился прирост где то в два раза, но зато начал немного глючить отрисовщик, так как я не смог добраться до методов именно расчета, кэшировал более высокоуровневые классы.
МЗ>Есть конечно выход купить сорс код и самому перелопачить там всё, но на это нет времени, а подтормажевание отрисовки наших юзеров не сильно волнуют.

Добрый день, Евгений и Максим!

Дело в том, что данный вопрос является очень актуальным для нашего проекта, т.к. планируется перейти на DevExpress grids вместо старого самописного grid-компонента. В наших grid-ах количество строк достигает 10-15 тыс. + используется 20-30 колонок, в том числе с графической информацией.
При этом известно, что в своё время разработчики отказались от VCL-грида по той же причине: медленный скроллинг. И реализовали свой компонент, где эта проблема была решена.

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

Надеюсь на весьма плодотворное сотрудничество. Кстати надеюсь, что мне удасться поспособствовать в разрешении данной проблемы по ряду причин, но для этого нужен конкретный пример, который до конца мне самому сэмулировать пока не получилось (у меня при 500 записях в БД тормозов вроде не наблюдалось, но может я использовал не тот пример или не тот компонент?)

Пишите на v.unosh@gmail.com — жду писем!!

Заранее благодарю,

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Господа, сталкивался ли кто-нибудь у DevExpress.GridControl с тем, что когда в нем находится например 1 тысяча записей, около 7 колонок с текстовой информацией, то при скролировании наблюдаются некоторые тормоза.

Да, знакомая вещь этот DevExpress XtraGrid. Что могу сказать насчет тормозов? Около дюжины столбцов, более двух с половиной тысяч записей, плюс еще свои обработчики навешаны — не то что бы явно тормозит, но некая медлительность присутствует. Если сравнивать с Excel, то разница конечно бросается в глаза, но с другой стороны я бы не сказал, что небольшая задумчивость грида мешает работе. Поэтому пока никак с этим не боролся — не вижу сейчас для этого причин. С другой стороны, не исключено, конечно, что на больших объемах данных тормоза станут более заметными, но тут только время покажет.

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


А> но для этого нужен конкретный пример, который до конца мне самому сэмулировать пока не получилось (у меня при 500 записях в БД тормозов вроде не наблюдалось, но может я использовал не тот пример или не тот компонент?)

Тормоза, о которых я писал — это тормоза не связанные с количеством записей в гриде. 500 или 5000 без разницы. В этом плане очень хорошо выразился господин TL, веточкой ниже: "не то что бы явно тормозит, но некая медлительность присутствует". Суть в том, что скролировние идет не в real-time режиме, чуть-чуть запаздывает. Для того, чтобы это увидеть надо просто форму с гридом развернуть на весь экран и вывести в грид несколько колонок, чтобы вся площадь грида была плотно заполнена, например, текстовой информацией. Судя по поведению грида у него отображаемая информация считывается в какой-то кеш и в пределах видимой области скролирование идет шустро, а вот если нажать скроллер и не отпускать его, когда начнут листаться страницы — вы увидите, что он начнет резко подтармаживать. Это связано не с объемом записей, которые помещены в грид (или его источник данных — в моем случае), а с алгоритмом отрисовки видимой области. Потому, что когда площадь видимой области небольшая тормозов незаметно. А если в сам грид еще и добавить каких-нибудь обработчиков, как писал TL, то ситуация еще более усугубится.

Кстати, для того, чтобы все это лицезреть во всей красе необходимо, чтобы машина у вас была не самая навороченная, а как у тех пользователей, для которых пишется система (как правило у них машины послабее, чем у разработчиков). И еще один неприятный момент, в процессе скролинга процессор кушается на все 100%. У других гридов такого нет — опять это неоптимальность алгоритмов.

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

TL>Да, знакомая вещь этот DevExpress XtraGrid. Что могу сказать насчет тормозов? Около дюжины столбцов, более двух с половиной тысяч записей, плюс еще свои обработчики навешаны — не то что бы явно тормозит, но некая медлительность присутствует. Если сравнивать с Excel, то разница конечно бросается в глаза, но с другой стороны я бы не сказал, что небольшая задумчивость грида мешает работе. Поэтому пока никак с этим не боролся — не вижу сейчас для этого причин. С другой стороны, не исключено, конечно, что на больших объемах данных тормоза станут более заметными, но тут только время покажет.

Еще разок подниму эту тему. Имел недавно возможность сравнить .NET и VCL версии грида — все-таки сливает .NET-версия в плане производительности по-черному Причем использование последней версии грида не сильно помогает — пробовал последние версии для .NET 1.1 и .NET 2.0 с сайта Developer Express — по сравнению со старой версией от 2004-го года сам по себе скроллинг осуществляется быстрее, зато вылезли чудовищные рывки, даже на небольших наборах данных. Более того, общая медлительность грида заметна даже по демкам от Developer Express — VCL-ные заметно шустрее — то есть это точно не особенность моего приложения. В общем, досадно конечно.

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


TL>Еще разок подниму эту тему. Имел недавно возможность сравнить .NET и VCL версии грида — все-таки сливает .NET-версия в плане производительности по-черному Причем использование последней версии грида не сильно помогает — пробовал последние версии для .NET 1.1 и .NET 2.0 с сайта Developer Express — по сравнению со старой версией от 2004-го года сам по себе скроллинг осуществляется быстрее, зато вылезли чудовищные рывки, даже на небольших наборах данных. Более того, общая медлительность грида заметна даже по демкам от Developer Express — VCL-ные заметно шустрее — то есть это точно не особенность моего приложения. В общем, досадно конечно.

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

Здравствуйте, Щербатов Евгений, Вы писали:

ЩЕ>Здравствуйте, TL, Вы писали:


TL>>Еще разок подниму эту тему. Имел недавно возможность сравнить .NET и VCL версии грида — все-таки сливает .NET-версия в плане производительности по-черному Причем использование последней версии грида не сильно помогает — пробовал последние версии для .NET 1.1 и .NET 2.0 с сайта Developer Express — по сравнению со старой версией от 2004-го года сам по себе скроллинг осуществляется быстрее, зато вылезли чудовищные рывки, даже на небольших наборах данных. Более того, общая медлительность грида заметна даже по демкам от Developer Express — VCL-ные заметно шустрее — то есть это точно не особенность моего приложения. В общем, досадно конечно.

ЩЕ>Полностю подтверждаю все вышесказанное! При этом я собственно даже в сапорт писал письмо на эту тему — идиотами прикинулись.... "где, что? я твоя не понимай..". Суть ответа была примерно такая, что ну надо же! вы первый такой кто жалуется, может у вас что-то не так — у нас все нормально. Даже отвечать им не стал. Вообще последнее время заметил за их сапортом не очень хорошую тенденцию. Загордились они что ли. Раньше на каждый вопрос отвечали обстоятельно и подробно, пытались сделать все что можно, для того чтобы клиент удовлетворенным остался, а теперь по большей части просто для профформы отписываются. На некоторые письма вообще не отвечают. Иногда по их ответам складывается впечатление, что специалистам техподдержки не хватает ума, чтобы понять суть вопроса и они его не доводят до разработчиков, а отписываются сами. — или просто под дураков косят. Но факт в том, что грид все тяжелеет и тяжелеет , а замечать они этого не желают.


Несколько вопросов:

скорость скроллирования смотрели запуская приложения из под студии или нет? (из под студии в 2-3 раза медленнее — ньюансы 2005 ).
какая версия грида?


Почему спросил? — только что ради интереса погонял — никаких проблем — ни при скроллировании через scrollbar, ни по pagedown/arrow down..

И заодно уж, сравнивать VCL и .NET некорректно. VCL — gdi — .NET — GDI+. Если в vcl включить double buffer, то скорости практически сравняются

/mk

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


А>Несколько вопросов:

А>скорость скроллирования смотрели запуская приложения из под студии или нет? (из под студии в 2-3 раза медленнее — ньюансы 2005 ).

без VS

А>какая версия грида?

7

А>Почему спросил? — только что ради интереса погонял — никаких проблем — ни при скроллировании через scrollbar, ни по pagedown/arrow down..

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

А>И заодно уж, сравнивать VCL и .NET некорректно. VCL — gdi — .NET — GDI+. Если в vcl включить double buffer, то скорости практически сравняются

что значит сравнивать некорректно? моему заказчику неважно VCL это или .NET, заказчик говорит — вот это работает хорошо, а вот это плохо.

Здравствуйте, Щербатов Евгений, Вы писали:

Раз уж вы с девами плотно работали, то спрошу, так как про суппорт вы абсолютно точно написали — прикидываются они ловко да и ответа ждешь чуть ли не неделю порой. Скажем в моем гриде, нужно каждую строку закрашивать своим цветом в зависимости от ее содержимого. Подцепился я к событию RowStyle, там значит беру значение ячейки (не стал брать всю запись по RowHandle, так как под профайлером это оказалось довольно узкое место), анализирую значение и выставляю нужный BackColor в свойстве Appearance. Заметил, что код также тормозит. gridControl.SuspendLayout/Resume в начале и конце метода помогли, но все равно отрисовка медленная, есть ли способы ее повысить? Заранее спасибо!

Здравствуйте, Щербатов Евгений, Вы писали:

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

А>>Несколько вопросов:

А>>скорость скроллирования смотрели запуская приложения из под студии или нет? (из под студии в 2-3 раза медленнее — ньюансы 2005 ).

ЩЕ>без VS

А>>какая версия грида?

ЩЕ>7
7.1 или 7.2 ? — + какой номер билда? — некоторые глюки со скроллингом были пофикшены недавно.
А>>Почему спросил? — только что ради интереса погонял — никаких проблем — ни при скроллировании через scrollbar, ни по pagedown/arrow down..

ЩЕ>схватите мышкой бегунок и попробуйте плавно потащить его вниз — увидите рывки.
на maindemo — не воспроизводится. хотя, тут может зависить от железа и системы — у меня vista+intel dual-core.
с другой стороны, там есть опция для любителей быстрого скроллирования — GridView.ScrollStyle — отключить LiveVertScroll...

А>>И заодно уж, сравнивать VCL и .NET некорректно. VCL — gdi — .NET — GDI+. Если в vcl включить double buffer, то скорости практически сравняются
ЩЕ>что значит сравнивать некорректно? моему заказчику неважно VCL это или .NET, заказчик говорит — вот это работает хорошо, а вот это плохо.
основным параметром системы, является не скорость скроллирования, а ее качество. и возможности...
основная задача грида, это быстрая работа с данными — сортировка, группировка, саммари и тд. Т.е., возможность быстро найти, то что нужно.
Как правило, для этого не нужно мгновенное скроллирование .

Самоме забавное, что в любом случае этот grid является самым быстрым на рынке. по всем параметрам — от скроллирования, до обработки данных...

/mk

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

А>Здравствуйте, Щербатов Евгений, Вы писали:

А>Раз уж вы с девами плотно работали, то спрошу, так как про суппорт вы абсолютно точно написали — прикидываются они ловко да и ответа ждешь чуть ли не неделю порой. Скажем в моем гриде, нужно каждую строку закрашивать своим цветом в зависимости от ее содержимого. Подцепился я к событию RowStyle, там значит беру значение ячейки (не стал брать всю запись по RowHandle, так как под профайлером это оказалось довольно узкое место), анализирую значение и выставляю нужный BackColor в свойстве Appearance. Заметил, что код также тормозит. gridControl.SuspendLayout/Resume в начале и конце метода помогли, но все равно отрисовка медленная, есть ли способы ее повысить? Заранее спасибо!

на скорость отрисовки, присвоение "e.Appearance.BackColor = xxx;" влиять никак не должно. если только логика получения этого Color'a, не слишком емкая.
А что касается suspendLayout/resumeLayout — внутри обработчика RowStyle event — это убийство . По идее грид должен умирать при этом.

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

//mk

Здравствуйте, Аноним, Вы писали:
.
А>А что касается suspendLayout/resumeLayout — внутри обработчика RowStyle event — это убийство . По идее грид должен умирать при этом.

Грид не умер

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

А>Здравствуйте, Аноним, Вы писали:
А>.
А>>А что касается suspendLayout/resumeLayout — внутри обработчика RowStyle event — это убийство . По идее грид должен умирать при этом.

А>Грид не умер
а должен был. особенно такое должно быть заметно при ресайзе формы