Hi
I have a xamDataGrid with 119 columns, and max 1000 rows, previously (in 14.1 version) I was using checkboxes to enable some of the columns based on predefined groups. This was a rather inconvenient way to achieve what I've wanted so when 16.1 came, I've upgraded to the newly introduced Field Group-ing method. The cells a few triggers set on them, and I use it with a fontsize dependent layout. Which are both business requirements so I can't throw them away. However the performance dropped drastically compared to the visibility setting, as far as I can see from the profiling it's because of the measure and arrange overrides are running for each added column. I've also tried to change the Fields to TemplatedFields and defined a DataTemplate for all of them which was empty (thus not showing any of the values), it is somewhat faster, but not much so I figure it's not due to the fontsize dependency or the triggers in the style. Can you please give me some sort of advice how to increase the performance? (also the we have by default a size 11 font, so about 45 lines are in view at once, this is also a business must). Sample attached.
Thanks
Maxie
Hello Maxie,
Thank you for your post on this matter.
I have been investigating the sample project you have provided and I would like you to take a look at the following blog post that outlines how you might be able to increase the performance of the XamDataGrid in this case: https://www.infragistics.com/community/blogs/kiril_matev/archive/2010/10/26/optimizing-xamdatagrid-performance.aspx.
I have profiled your sample project and have also seen that the Measure and Arrange override are most of the performance issue in this case. This is not entirely surprising, as when you expand your FieldGroups in this case, you are causing quite a few cells to come into view as it appears many of these FieldGroups contain between 5 and 10 Field elements. Since you are showing about 45 records at once, this leads to the creation of around 250 - 500 cells on expansion of a particular FieldGroup, which can take some time.
Inside of the blog post mentioned above, there is a mention of "Minimalist" styles along with a download link for the ResourceDictionary that makes up these minimalist styles. I see that you are currently using a custom CellValuePresenter style that seems to mostly have been trimmed, although it still has the ContentPresenter "PART_EditorSite" included. This ContentPresenter is used internally to essentially host a ValueEditor-derived element used for editing the CellValuePresenter, essentially making the CellValuePresenter larger. It appears that you are trying to disable editing in your XamDataGrid anyway, and so these "minimalist styles" should help you in this case, as it replaces this ContentPresenter with a TextBlock - removing the embedded editors and making the CellValuePresenter a bit more lightweight, and so it should render faster.
The "minimalist" styles also include separate styles for the DataRecordPresenter and DataRecordCellArea elements to make them more lightweight as well, although these mainly remove the hover styles, and I am unsure if this is an option on your end.
I hope this helps. Please let me know if you have any other questions or concerns on this matter.
Sincerely,AndrewAssociate Developer
Hi Andrew
I've read Kiril's article about optimizing, however I didn't want to completely change the styles as I don't know what it can cause in the end, I'd like to keep the style change on hover as well. About removing the PART_EditorSite I wonder if using the TemplatedField with a DataTemplate is any different, cause in that case we only have the MainBorder, the Active1 for hover, and the PART_EditorSite containing a single TextBlock. Which I've tried as stated previously and the performance didn't change much compared to the sample version. I will be needing the MainBorder, the hover style(Active1) and the TextBlock anyways, so there is no way to work around that. I was actually wondering if there is a way to disable the sizing and thus Measure and Arrange for the Cells while expanding, and reenable it once it opened. Or having their just Visibility changed (not their size) upon group open cause that seems to be doing what we need.
Using a TemplateField with a DataTemplate containing only a TextBlock is different than modifying the template in that a ValueEditor derivation is still hosted in the CellValuePresenter classes. This would lead to a CellValuePresenter with a TemplateEditor element inside of its PART_EditorSite, which then hosts the content of the template that you provide. When changing the CellValuePresenter template, to only include a TextBlock, though, the only thing that will exist in the CellValuePresenters will be the Borders and that TextBlock, making them a bit more lightweight.
I have been investigating a bit further today into the exact operations that happen when a FieldGroup is expanded, and it appears to me that the FieldGroup expansion essentially brings the corresponding Field elements into the grid, leading to the corresponding cells needing to be measured and arranged, and the records in view needing to be rearranged as well, since the makeup of the cells has changed. It is not currently possible to disable the Measure and Arrange for these cells, as this would likely lead to nothing actually being rendered where those cells should be.
The Visibility change that you have mentioned might work, but I believe you would need to revert back to your original method of programmatically showing and hiding Fields in your grid. I am rather unsure why this original method seems to work better for you than the FieldGroup at the moment, but am in conversation with our developers about this to see what other performance optimizations might be able to be made to the XamDataGrid in this case. I hope to have more information for you on this shortly.
Please let me know if you have any other questions or concerns on this matter.
I have received an update from our development staff on this, and they would like to take a closer look at how the performance of the FieldGroup expansion and collapse operations may be able to be further optimized. To ensure that this receives attention, I have logged this issue in our internal tracking systems with a development ID of 243621.
I have also created you a support case with an ID of CAS-187700-K3B0G9, which I will be linking to this issue so that you can track it. You can access this support case after signing into your account on the Infragistics website at https://www.infragistics.com/my-account/support-activity.
I will be sending an initial update to this private support case shortly with additional information regarding this development issue link.
Thank you Andrew, looking forward to it! :)
Regards,