Hi,
We are using UltraWinGrid to display frequently updated data. The datasource is set to BindingSource which in turn takes a dataset. When there are a lot of updates coming in at the same time, the CPU usage spikes. It appears a GUI painting issue because when we shrink the application window to make updating region invisible, CPU usage comes back to normal. Is there a way to optimize grid painting performance? Would virtual mode help?
Thanks.
Simon
I don't know if a MouseMove event is the best place to do this in the grid, especially since cells will already be invalidated when you mouse over them, so you might be doubling up on the amount of work being done. Why do you need to do this many updates, and are you only updating the cell over which the mouse is positioned, or are you updating all of the data? You might be able to leverage the CellDataRequested event of the UltraDataSource if you need to get an updated value instead of relying on the MouseMove.
-Matt
I'm running into the same problem, I'm using the most recent version (8.3) and am using an UltraDataSource to drive the data for the grid. I'm updating the data directly in the data source base on a MouseMove event which when over the appropriate form fires frequently. All updates are surrounded by Begin/EndUpdate and Suspend/ResumeRowSynchronization blocks, but I'm still seeing a CPU spike during any update. I do not see any CPU spike when I resize the grid so it's no longer showing, eg so that the form is only the title bar. I'm at a loss as to what more I can do to eliminate this innefeciency, any suggestions?
The performance increases were made in 7.3, which is applied to all versions after that. Have you taken a look at the WinGrid Performance Guide? I really can't say why your grid would be using so much memory or why it would be crashing without the app. Assuming you're doing everything you can that is mentioned in the performance guide, you should probably submit a sample to Developer Support.
I am using 8.2.2 (Version 8.2.20082.1000). Is the same performance enhancement in 7.2 that you mentioned applied to this newer one?
The CPU spike, along hugh memory increase is constantly crashing the application.
Simon,
I'm not entirely sure what could be causing this then. If the grid is getting repainted without any other sort of trigger (i.e. resized, obscured and then made visible, etc), then it must still be getting some sort of notification. You could always prevent the grid from painting through the methods I suggested previously, but the problem is knowing when to start/stop doing this, which is why I suggested looking where you pull in your data. Whn you say you are "listening to a database", you must still be actively doing something that is pulling the data in from the database somewhere, even on a separate thread, so I would look towards that area. I would also consider looking into using 7.3 or later if you have the subscription since you should definitely notice a decent improvement.