Question
========
How do you configure a datagridview so it will be drawn/painted fast
The whole DataGridView should be drawn at once and not individual cells one at a time.
Problem
=======
We have a Windows.Forms application in which we populate a DataGridView (.NET 2, NOT DataGrid)
with objects contained in an ArrayList.
The problem is that we can see when each cell is being rendered. It works really slow.
Once it's rendered it works quite fast. But it's slow when another window has
been on top of the window with the datagridview in it. And you put the application
window on top again. It's the same if we use a TabControl and switch tabs.
When we switch to the the tab with the datagridview you can see each cell being rendered.
Thoughts
========
These thoughts are perhaps wrong...
We have searched the web for an indication of what to do but not found anything that we have managed to use/get to work.
We have tried several things (provided we have managed to implement them correctly)
"Ordinary" DoubleBuffering doesn't fix our problem, doublebuffer the whole paint operation instead But how do you do that
We know we haven't managed to do that since we can see each cell being rendered (else everything should have been displayed together).
We tried SuspendLayout, ResumeLayout, but perhaps in the wrong place How do you intercept the update of a form
and turn the layout off an on before and after the "painting" And does it help
We think that our problem it self is perhaps a generic one that has to do with update/painting of controls/forms.
But it's only noticable to us when using a datagridview that contains more data than
a simple form with textboxes, radiobuttons,... usually contains.
Example application
===================
We have made a minimal sample application that illustrates our problem.
Each object has 31 Properties that are rendered in the DataGridView and the ArrayList
contains 50 objects. 11 rows are visible.
[MainForm.cs] http://www.kalmarit.se/dotnet/MainForm.cs
[MainForm.Designer.cs] http://www.kalmarit.se/dotnet/MainForm.Designer.cs
[Program.cs] http://www.kalmarit.se/dotnet/Program.cs
Our configurations
.Net version: 2.0.50215
System 1 System 2
RAM: 630 Mb 256Mb
CPU: Duron 1.2 GHz 1.6 GHz
OS: Windows XP Windows XP
We are most greatful for any help we can get!
Slow rendering
Ivan Starr
try catching the cellformating event of DGV.
The thing about suspendlayout and resumelayout is that they only affect the DGV at the highest level - for example, H-scroll and V-Scroll bar may not show if you suspendlayout. The problem is at the cell level, you don't have suspendlayout or resumelayout. As a test of this theory, I simply suspended layout of my DGV and tried adding rows programmatically - and the rows continued to be added, but the vertical scroll bar wouldn't show until i called the resumelayout method.
In an earlier implementation of my app, I also used the ArrayList as a datasource. But I had to take that one step further and create a BoundingSource object so that I could control the Properties of my objects to display in each column - hence my DGV was bound to my BoundingSource object. This seems to work fine until I realized I needed to modify cellstyles as well.
In my most recent implementation, I simply stuck to manually inserting each row of the DGV - and just before I insert the row, I would assign my data-object to the Tag property of the DataGridViewRow object. At the same time, I could change the style of the row and wouldn't have to bother with DGV's Paint/RowPrePaint/RowPostPaint/CellFormating events. The end result was a significant improvement to performance espeically with large amounts of rows in my DGV.
Finally, I had another performance issue when trying to add many rows to the DGV at one time - you could essentially see each cell being drawn on the DGV, and the more columns/rows to add at one time, the worse it becomes. I decided to simply Hide my DGV using the DGV.Hide() method and using DGV.Show() method when I finished updateing the DGV. This seems to improve performance even further.
hope these ideas helped.
freka586
Regards,
Saurabh Nandu
Patrick Grimme
Right. SuspendLayout() doesn't directly affect the drawing of the control. Paint events are still fired and processed normally. I think your approach of hiding the control while you're changing it is probably a good one.