DataGrid slower in framework v2.0?

[EFileTahi-A]

I have this small application in Framwork v1.1 which loads an Access database and show its insides onto a DataGrid object. This task only takes about 5 seconds or so, to show the database's contents (11MB Access file with about 900 records with 40 columns).

 

I opened then the very same project in Framework v2.0. After the conversion I executed it and now it takes like 14 seconds to display all data into the DataGrid...

 

My question is:

Is DataGrid slower in v2.0 or is actually the Framework's fault?

 

I never worked with databases in VS 2005, so, I really need to see whats going on before moving to VS 2005.

 

Thank you

[JumpyNET]

I asked this once and someone told me that DataGridView uses GDI+ drawing engine and for this reason it's rather slow.

 

Here's the link:

http://www.xtremedotnettalk.com/showthread.php?t=95433

[EFileTahi-A]

Thank you JumpyNET.

 

I guess these are bad news then... I Will have to rethink some things...

 

 

I also noticed some person saying to us to wait until GDI+ gets hardware accelerated by cards supporting GDI+. This would be really cool but, my question is:

 

Should the card be the one supporting this feature? Or should microsoft modify GDI+ in order to get it accelerated by existing hardware?

 

I guess the second option makes more sense...

No? I mean, GDI+ is 2D, would it be too hard for microsoft to use the 2D accelerated instructions of our graphic cards do draw GDI+?

 

What do you think?

Edited June 5, 2006 by EFileTahi-A

[snarfblam]

GDI+ is, in certain aspects, sorely lacking in optimization.

 

It is very flexibly: images can be scaled with different options of interpolation and units and vector graphics can be anti-aliased. There are a variety of types of brushes, and on top of all that GDI+ supports transformations (translate, scale, rotate). As a result, though, the most basic graphic operations suffer performance-wise. Even without graphic acceleration, unscaled blits between images with the same pixel format should be lightning fast, as should simple vector operations, but these simple optimizations are missing.

 

GDI+ is, depending on circumstances, notably faster in version 2.0 of the framework, but, sometimes, GDI still manages to put it to shame.

[Diesel]

Try SuspendLayout/ResumeLayout.

 

Also, you realize that the previous post was talking about the MSFlexGrid...not the .net 1.1 framework grid.

 

I don't see how the drawing functions could be that much slower, especially in an evolved version of the libraries.

 

Are you loading in the data in the exact same way?

[EFileTahi-A]

Try SuspendLayout/ResumeLayout.

 

Also, you realize that the previous post was talking about the MSFlexGrid...not the .net 1.1 framework grid.

 

I don't see how the drawing functions could be that much slower, especially in an evolved version of the libraries.

 

Are you loading in the data in the exact same way?

 

Yes, exactly the same way.. I just converted the application from v1.1 to v2.0 and did not changed a thing...

[snarfblam]

I don't see how the drawing functions could be that much slower' date=' especially in an evolved version of the libraries.[/quote']

Most people are hesitant to believe it, but this type of thing is more common than people tend to realize (for example, each successive version of Word seems to boot noticeably slower [yet suits my needs no better than the previous version]). Do some benchmarks. You will see that .Net 2.0 usually blits faster than .Net 1.x and almost always, if not every time, performs equivalent blits slower than GDI. The simple reason that this happens is because Microsoft made flexibility and capability a much higher priority than performance.