Hi,
I’m currently using XamPivotGrid with a FlatDataSource bound to an ObservableCollection containing about 1500 items. The source object class consists of 10 members. Three of them are measures and three of them are dimensions. If I expand all hierarchies and start to scroll through the grid, I experience a bad scrolling performance.
| YearM1,M2,M3 | 2007 | 2008 | ... | 2016 | | M1,M2,M3 | M1,M2,M3 | ... | M1,M2,M3 |------------------------------------------------------------ Type | Name1 | | .... | | Name 99 |
After having analyzed my application with dotTracePerformance I found out that the ‘RenderCell’ method took a lot of time and caused the problem.
Is there any possibility to fix this problem?
I’m also facing similar scrollbar performance issue with XamPivotGrid. The XamPivotGrid uses FlatDataSource bound to an ObservableCollection of 300 items.The visible columns are only 7.When applying filter on 3 columns, the scrollbar performance becomes very bad. Can you please provide some suggestion to improve the scrollbar experience with multiple filter columns.
Hello Mirco,
I am just checking if you need any further assistance on the matter.
Currently this is the best approach for optimizing the performance of the XamPivotGrid. The thing you can do is suggest a new product idea for deactivating auto-sizing here:
http://ideas.infragistics.com/
Hello Stefan,
thank you for your fast replay. I have removed the dimension 'Type' and reduced the 'Name' rows from 100 to 50. Now I have 1500 cells in the pivot grid.
Can you recommend any other solution than cutting down the number of visible cells? Is it possible to deactivate the content based auto-sizing mentioned above? Moreover, I have recognized a slight delay in navigating through the visible cells of the grid using the arrow keys. How can I fix this problem?
Thanks in advance,
Mirco
Hello Mirco,Our developers have investigated this issue and have provided the following response:
"The performance of the XamPivotGrid is determined by the amount of visible cells and the complexity of the headers hierarchy. There is no bug when the size is changed and the columns are hidden – the XamPivotGrid works as designed in those situations. Setting the size results in more cells to visualize and hiding the columns complicates building the hierarchy. Event after the designed behavior is refactored to improve the cell by cell scrolling when a whole new page is scrolled into view all the Cells need to be re-rendered. This being said the XamPivotGrid is designed to show complex three dimensional data and its internal relations and not for displaying thousands of scrollable cells that are useless for reading data from the screen. The optimization is based on redrawing only the newly scrolled into view cells, instead the whole screen every time.
This is not a bug since the control works as intended in its design. After a thorough inspection of the scrolling functionality there seemingly were a couple of places that could get improved. After performance profiling it was determined that the most time-consuming action is the Cell rendering. This is so since for every single scroll all of the visible cells are redrawn. This is needed mainly for two reasons. One is because the XamPivotGrid utilizes item based scrolling, which afterwards is masked as smooth-whole-width-based scrolling via some calculations based on the cells widths. The other is the XamPivotGrid’s rows’/columns’ content based auto-sizing. This allows the rows/columns to always be stretched as much as the widest/highest cell that comes into view, or is dynamically resized via a style or runtime code. Preserving these features prevented us from minimizing the cell rendering to the number of cells that exited and came into view."
As stated about, the performance of the pivot grid is determined by the number of visible cells. If you can cut down on the number of visible cells, the performance should get better.