We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. (Last updated on : November 16, 2018).
Unfortunately, activation email could not send to your email. Please try again.
Syncfusion Feedback

Virtual Grid Performance For Real-Time Data

Thread ID:

Created:

Updated:

Platform:

Replies:

11820 Mar 16,2004 06:31 PM UTC Mar 23,2004 04:57 PM UTC WinForms 5
loading
Tags: GridControl
Aaron Jackson
Asked On March 16, 2004 06:31 PM UTC

I went out on a limb and figured that a virtual grid would be a decent model for displaying some data which is coming in in real-time (stock market trades, etc). The problem I''m running into is that the underlying data source is a fifo that is displayed in an inverted fashion (i.e. new items are displayed at the top of the grid, older items are displayed towards the bottom). The list length is only about 100-200 items, but I''m finding it very difficult to get reasonable performance out of the grid. I figure the underlying data source is updated about 10 times per second during its peak points. I dont want to call ResetVolatileData whenever new information is received, but since the must actually shift up and out of the way, I dont know of any other mechanism to handle this. The combination of ResetVolatileData + Refresh is eating any performance benefit I may have expected. Even when there is no movement, resizing my form (the grid is docked [fill] inside the form) has very distinct "freeze" points. As the size of the window approaches the client area of the grid, the paint time increases considerably and I get very choppy UI response. Any help is appreciated.

Administrator [Syncfusion]
Replied On March 16, 2004 11:12 PM UTC

There are quick ways to get this done. I will try to post a sample some time in the next day or so. The idea is to not call Refresh, but to actually call WindowScroll to just scroll the window to make room for the new row at the top. You then only have to redraw 1 row instead of all visible rows. The grid have optimization modes that will get this done. One question for you. If your datasource only has 200 rows, and you get 20 inserts a second, what happens to the ther rows? Do they just fall out of the row collection. If so, I would think a circular data structure would be efficient.

Aaron Jackson
Replied On March 17, 2004 10:50 AM UTC

Actually, I do use a circular representation internally. The idea is to display the last N items that have occurred. To that end, the items at the "end" of the list are the first to be "truncated". We dont really truncate as you might guess though. I look forward to seeing your sample.

Aaron Jackson
Replied On March 17, 2004 05:02 PM UTC

I can handle generating the WindowScroll event (I''m assuming you''re referring to Control.ScrollWindow), but you mentioned optimization modes. What are these optimization modes and how to I set them.

Administrator [Syncfusion]
Replied On March 17, 2004 05:47 PM UTC

Actually, handling the scroll will have the most impact and will give you much better performance. The optimizations I as referring to are illustrated in the grid\samples\performance\refresh sample that is part of the 2030 release. They require teh 2030 code. Using the Scroll does not.

Aaron Jackson
Replied On March 23, 2004 04:57 PM UTC

Clay, I actually have a follow-up to this. I''ve gone through this model a few time but the results have actually been rather disappointing. I have a thread that is updating my data structure and firing off events for System.ComponentModel.CollectionChangedEventHandlers. However, I find that the data flows in rather quickly and while 70% of the time the scrolling works fine, the other 30% of the time, the rows dont render properly. I''m thinking that the paint routine is interleaving with my requests to scroll the window. Naturally that would screw up the display because it might not have painted the "0" row even through I am forcing it to scroll. So I moved the event handling into the STA thread via Invoke, but got the same type of "blurring" of sorts in the window. Here, I''m guessing that the area is invalidated, but that the WM_PAINT posts somewhere between my updates and I get the same effect. So I see (add row [scroll], add row [scroll], paint). Ugg, just doesnt look right. My only thinking now is that I''d have to enqueue these updates and only apply the scroll during the painting. Either way, this doesn''t sound like a good solution. Any insight on your part?

CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

Warning Icon You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.Close Icon

;