User (Old forums)MemberFebruary 7, 2005 at 3:19 amPost count: 23064
I’ve been researching grids for the framwork for the past week or so and come to the conclusion that what one grid offers might be what you’ve missed in another, but what you’ve liked in that other grid might be missing in the first one.
Xceed’s grid control is excellent, except for it’s performance as far as user interaction goes. Maybe it’s the machine I’m working on, but scrolling, expanding hierarchies, adding rows and what not as a user is slow. Every operation is sluggish to say the least. On the other hand all operations seems to be about as slow as the other. Maybe it indeed is the machine I’m working on (old intel p3 cpu running at 600MHz, 256mb ram (yeah I know, don’t bust my chops), etc.) but I’d like to know for certain. I’ve recently tried SyncFusion’s EssentialGrid and it, while being sluggish in some areas, outperforms Xceed’s grid by far. Scrolling is fast, expanding hierarchies is fast, adding rows is still slow ;o)
But as I put it before, the other isn’t neccessarily better than the first. Whilst Syncfusion’s grid is far faster on my machine (I have yet to try them both on other machines) having thousands of items in it, Xceed’s is in my opinion much nicer when it comes to looks. And looks is halft the user experience at least. My app is tons more easily overviewed and edited with Xceed’s grid than Syncfusion’s, be it not for performance issues.
Does anyone else have experience with this and would like to share?
Imported from legacy forums. Posted by macke (had 12531 views)User (Old forums)MemberFebruary 7, 2005 at 3:55 amPost count: 23064
Xceed.Grid can indeed be slow, but you can make it faster. The applications our company makes heavily depend on Xceed.Grid for both output and input. We have grid controls with thousands of rows, lots of columns, builtin filter mechanism, custom viewers and editors. By subclassing Xceed.Grid classes, and creating our own cell viewers and editors, we’ve managed to make it a lot faster, and add more functionality.
One thing I’ve seen that really makes the grid slow is when you use a GridComboBox as a CellViewer, and that GridComboBox is bound to a DataSource with lots of elements. Each time a cell has to be painted, the GridComboBox has to take the value of the cell, find the record in its DataSource with that value, and display the DisplayMember field.
Imported from legacy forums. Posted by Tommy (had 204 views)User (Old forums)MemberFebruary 7, 2005 at 4:25 amPost count: 23064
What about time? How long does it take and how intricate a process is it to subclass the grid and write painting code (I assume this is what makes your grid faster?).
As it is now I’m pretty short on time, and don’t think I’ll be able to subclass in order to speed things up.
Imported from legacy forums. Posted by macke (had 116 views)User (Old forums)MemberFebruary 7, 2005 at 5:45 amPost count: 23064
Well, we didn’t subclass the grid to enhance performance, but to add functionality. Later we discovered that, by overriding parts of the functionality, we could also make it faster.
It all depends on your application. Could you tell me how you use the grid, what kind of datasource you bind to, how many rows/columns there approximately are, what kind of CellViewers and CellEditors you use, …?
Imported from legacy forums. Posted by Tommy (had 59 views)User (Old forums)MemberFebruary 7, 2005 at 6:04 amPost count: 23064
Thanks for taking your time Tommy,
I’m using the grid to display the members of a local sports club.
My layout looks rougly like this:
|- Member ID (int)
|- First name (string)
|- Last name (string)
|- Civic registration number (string)
|- Detail grid “Address”:
|– c/o (string)
|– Street (string)
|– Zipcode (int)
|– City (string)
|- Detail grid “Contact”:
|– Home phone number (string)
|– Cellphone number (string)
|- Detail grid “Membership”:
|– Status (string, combobox)
|– Join date (DateTime, date picker)
|– Exit date (DateTime, date picker)
|– Newsletter (bool)
|– Detail grid “Sections”:
|— Section (string)
|— Detail grid “Functions”:
|—- Function (string)
|—- Award (string)
As you can see there are a bunch of detail grids, which I at first figured might be a problem. But even when I eventually tried stripping the detail grids and only retaining the master grid I ran into performance issues. Every grid has an input row btw. What parts of the grid did you override to make it faster?
I’m binding the grid to a dataset, it doesn’t seem to make much difference as far as performance goes to loading data into the grid manually, I tried that as well. Is the Xceed grid filled with data on demand or is the whole grid filled?
Imported from legacy forums. Posted by macke (had 703 views)User (Old forums)MemberFebruary 7, 2005 at 6:49 amPost count: 23064
In our applications, the grid is usually bound to a DataTable that is filled in one time. Looking at the cellviewers of your grid, I see only 1 combobox (status), which probably doesn’t have a lot of elements.
It might also be because of the visual appearance of the grid: are you using stylesheets or images?
Another problem might be memory usage. If there’s a lot of data, the GridControl creates a lot of small objects. You said you’re binding to a DataSet. DataSets are also known for using a lot of memory.
Subclassing the GridControl doesn’t really let us enhance performance, just functionality. The higher performance is because we subclass the Xceed.Grid.DataRow and Xceed.Grid.DataCell. The methods of DataCell we override are: PaintBackground and PaintForeground.
Because we don’t use transparent background colors and background images, we can write a faster PaintBackground, like this:<code>protected override void PaintBackground(GridPaintEventArgs e)
using (Brush b = new SolidBrush(GetBackColorToPaint())
The standard PaintBackground probably checks if there is a background image, or if the background color is transparent.
And because cells in our grid never have a transparent background, the parent DataRow doesn’t have to paint its background every time. So you can override the PaintBackground method of the subclassed Xceed.Grid.DataRow, and just do nothing in it (don’t call base.PaintBackground!), like this:<code>protected override void PaintBackground(GridPaintEventArgs e)
// do nothing
Imported from legacy forums. Posted by Tommy (had 365 views)User (Old forums)MemberFebruary 7, 2005 at 7:28 amPost count: 23064
No, I’m not using any images or stylesheets, and the combobox holds but four items. Your suggestion is good, I will try that. I have no need for fancy pants rendering anyhows.
The memory argument seems quite valid, I wouldn’t be surprised if Windows is paging a lot during all this considering the low amount of memory in my machine. I’ll try on another machine as well to see if this holds true.
Thanks for taking your time to help me out Tommy, I really appreciate it! I’m going to try your suggestions and see what I come up with.
Imported from legacy forums. Posted by macke (had 381 views)User (Old forums)MemberFebruary 7, 2005 at 1:34 pmPost count: 23064
Unfortunatly the issue persists. I’ll have to continue researching but leave it be for now I suppose. Thanks again for the help though Tommy!
Imported from legacy forums. Posted by macke (had 426 views)Xceed SupportMemberFebruary 8, 2005 at 2:08 pmPost count: 5658
Tommy, you are right, overriding the PaintForeground and/or PaintBackground without calling base is something that can do a big boost.
To boost performance of the detail, you can feed detail grid only when they expand (Setting them to collapse by default on the DetailGridTemplate) by handling the CollapsedChanged event.
One thing to try, is overriding the PaintForground. In it, check if calling a Graphics.DrawString with a StringFormat that have less option activated (like no word wrap … etc) in the StringFormatFlags can speed up your apps. There is also some setting on the Graphics itself that can change performance, like TextRenderingHint, changing this setting may give you more speed (Or less speed also).
I will be very interested having a sample app that shows the performance hit on the machine you have. Then we can check on our side what can be done to boost speed up.
You can send it to firstname.lastname@example.org, just precise in the email that is for Francois Carignan.
Imported from legacy forums. Posted by Francois (had 328 views)User (Old forums)MemberFebruary 10, 2005 at 7:38 amPost count: 23064
I’m sorry Francois but for now I simply don’t have time to write up a sample app. I will definatly consider that later on when this project is finished. Thanks a bundle for the offer!
I’d like to know a couple of things though. Am I right in assuming that the only actual painting done by the grid itself is the background? Am I also right in assuming that all the elemnts that get painted are done so by having each sub-control paint itself? In that case I’d have to make my own classes that inherits from Cell, Column, Row etc.?
For now I’ll have to live with the performance hit. I’ve tested this on another machine and whilst it was noticable (or it’s simply a phantom effect ;o)) it was significantly improved.
Thanks for helping!
Imported from legacy forums. Posted by macke (had 560 views)User (Old forums)MemberFebruary 10, 2005 at 9:11 amPost count: 23064
Oh my god, I just realized that I totally misread your reply Tommy. I thought you meant subclassing the Grid itself. I must have more coffee. I’ll try subclassing DataRow and DataCell right away!
Imported from legacy forums. Posted by macke (had 333 views)User (Old forums)MemberFebruary 10, 2005 at 9:22 amPost count: 23064
Good news, the effect is indeed quite noticable! I’ll go on with Francois suggestions and see if it’s possible to make it even faster. Thanks a lot for your help guys!
Imported from legacy forums. Posted by macke (had 434 views)User (Old forums)MemberSeptember 9, 2005 at 5:07 pmPost count: 23064
when you say you subclass the DataRow and DataCell objects could you be more specific? I’m thinking along the lines of inheriting from those objects into my own user control and if that’s what you mean ,you couldn’t use the WYSIWYG editor, and I assume you add all of your rows/cells by code? Is there some easy way of doing this I’m overlooking? I tend to do that.
Trying to see if this is something I want to look into to speed up my load time on my forms…
Thanks in advance
Imported from legacy forums. Posted by AndyJ (had 414 views)User (Old forums)MemberSeptember 10, 2005 at 10:45 amPost count: 23064
Well, you could use the WYSIWYG editor to put the grid on the form, set its properties and add the rows and columns. Then, in code, you can replace the default DataRowTemplate of the grid with an instance of your own DataRow-class. If the grid creates its rows and cells, it just makes a copy of the DataRowTemplate.
Like this:<code>grid.DataRowTemplate = new MyDataRow();</code>You can put this line of code in the constructor of your form, right after the call to InitializeComponent.
Imported from legacy forums. Posted by Tommy (had 264 views)User (Old forums)MemberSeptember 10, 2005 at 12:50 pmPost count: 23064
alright I did this and can’t notice any increase in performance… where do I put the subclassed cell at in the grid? I’m new to this object model sorry for having to ask all these dumb questions…
Imported from legacy forums. Posted by AndyJ (had 431 views)
- You must be logged in to reply to this topic.