Высокая частота обновления Telerik radgridview

Question

В приложении Winform, Я следующий сценарий:

1. Гнездо принимает данные с высокой частотой (150-200packets х секунду)
2. Я вид сетки, что заполняется на декодированного пакета, принятого
3. полученный деталь может быть новый элемент или обновление предыдущего one..there're 5possible значение, которое может быть обновлена ​​
4. элемент GridView находится в режиме виртуализации: на

Поскольку я не могу привязываться к BindingList (он заморозит поток Ui), я решил использовать очередь и обновить сетку на основе таймера. Когда истекшее событие таймера перерабатывается я обновить GridView, призывающую к gridview.TemplateMaster.Refresh(), заставляющий cellValueNeeded называться

Это самое быстрое решение я нашел, но у меня есть некоторые проблемы:

1. я не могу знать, какой столбец было обновлен
2. Используя виртуализацию причины мне называть cellValueNeeded каждый раз, и мой список практически бесполезно, я могу использовать его в качестве би одномерного массива
3. Я к заказная сортировка сортировки/фильтра/столбца

У кого-нибудь из вас есть лучший подход? Благодаря

Answer 1

Учитывая следующую дополнительную информацию:

У меня есть 8 столбцов ... номер строки зависит от какой элемент перетаскивается из TreeView ... в этом тесте я получило 256 строк, но может быть более ... для второй точки Если я rebing всего ItemSource я теряюсь, что обновлено

ваш вопрос гораздо более сложным, чем ваш OP предлагает. Фактически у вас есть два источника изменений, которые изменяют сетку и базовые данные. Один из ваших входящих пакетов данных, а другой - пользователь. У вас также есть 8 * 256 = 2048 элементов, чтобы показать пользователя. Это много. И из моего понимания OP пользовательский интерфейс потенциально может быть обновлен до 1000 новых значений каждую секунду. Это не является полезной функцией, так как ни один человек не может быстро обрабатывать информацию.

Таким образом, учитывая тот факт, что пользователь может произвольно тянуть в данных в сетку с точкой зрения дерева и ваш пакет приемник может добавить или обновить тысячи ячеек сеточных данных в секунду, я хотел бы предложить совершенно другой подход:

• Держите коллекцию очереди, которая содержит входные данные
• Добавить три новые части UI чуть выше сеток:
  • только для чтения управления (простое управление меткой будет делать), что отображает количество обновлений в настоящее время очередь
  • Временная метка, когда сетка была в последний раз обновлена ​​из очереди пакетов данных
  • Кнопка, которую пользователь ударил вручную, чтобы вытащить данные в очереди. При нажатии на кнопку будет сбросить временную метку, чтобы текущее время и количество находящихся в очереди элементов в 0
• Вы можете также сохранить таймер для автоматического обновления данных, но сделать его умнее:
  • Продлить период времени между автоматическими обновлениями
  • Сбросить таймер всякий раз, когда пользователь взаимодействует с пользовательским интерфейсом (это в основном создало бы ситуацию, когда сетка автоматически обновляется только тогда, когда пользователь «простаивает» или не взаимодействует с пользовательским интерфейсом)
• Столбцы, перемещаемые вокруг, не являются проблемой, так как вы можете найти/и ссылаться на столбцы по их имени столбца, а не по их индексу.
• Поскольку сетка может быть отсортирована произвольно пользователем, вам нужно использовать функцию поиска для идентификации строка для обновления. Вы должны иметь какое-то (первичный/уникальный) ключевой столбец, видимым или скрытым, с помощью которого можно определить строку и основной объект
• Все остальные функции остается тот же

Оригинальный ответ для потомков:

Я предлагаю создать новую коллекцию, которая будет общим ресурсом между пользовательским интерфейсом и вашим потоком сокетов (при условии, что у вас есть поток для связи сокета). Вы обновили бы эту коллекцию, а также отметку времени последнего изменения. Этот флаг важен, потому что вы не измените его, если данные действительно не изменились. У вас также может быть дополнительное поле, в котором можно было бы подсчитать количество обновлений с момента последнего изменения. (Я предполагаю/надеюсь, что большая часть этих данных не будет отличаться.)

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

Answer 2

Я также рекомендовал бы иметь взгляд на эту статью: High Performance with RadGridView and Virtual Mode including Filtering, Sorting and Grouping