Hi Steve, 

Steve Liu said:

Firstly, maybe I misunderstood that you meant the grid does re-calculations every time when you said "When you scroll and some new summary cells come into view, the grid has to loop through all of the rows that apply to that summary." 

What I meant by this is that the summary gets calculated the FIRST time it's scrolled into view. That assumes, of course, that no one asked for the summary value prior to that, which would require it to be calculated earlier. 

If you want to force the summaries to be calculated up front, you could do that very easily by simply asking for the value in code. for example, for root-level summaries, you could do this: 

 foreach (SummaryValue summaryValue in this.ultraGrid1.Rows.SummaryValues)
 {
     object o = summaryValue.Value;
 }

Of the top of my head, I can't think of any reason why scrolling should be slow the second time you scroll the sumnmary into view, but maybe there is some reason the grid needs to check to see if it's dirty and need recalculating or something. If you can provide a small sample project that demonstrates that behavior, we could look into it. 

Allow me to update with some more testing result. It does seem it improved quite a bit during subsequent scrolling after first complete round of scrolling down. But still the scrolling seemed delayed somewhat, comparing to, if I remove all summary rows, the scrolling up and down will then be smooth as it should be in a normal grid.

On your point "The summaries are not calculated until the summary cell is scrolled into view (or someone asks for the value) because that would be a waste of CPU cycles to calculate something no one needs. ", I actually disagree.

If I can set it to do all calculations in the beginning, at least, I can get the report running while I go on a coffee break and come back with a useful report to scroll up and down other than now it's impossible to scroll up and down at all!

Hi Mike,

Thanks for the quick response.

Firstly, maybe I misunderstood that you meant the grid does re-calculations every time when you said "When you scroll and some new summary cells come into view, the grid has to loop through all of the rows that apply to that summary." 

Secondly, I suspect that is the case because even after I did one complete round of scrolling down and up (took forever to achieve that by the way, painful!), the performance didn't seem to get much better when I try to scroll it down again. So I am suspecting some processing is still happening during second+ round of scrolling down.

Just FYI, in our case, we have 83 columns and thousands of rows of raw data plus 15 summary rows. If I turn off the 15 summary rows, scrolling up and down is not a problem. So whatever is happening, it has something to do with the summary rows.

-Steve

Hi Steve, 

It might depend on whether you are using the build-in summaries or the CalcManager, but I doubt the grid re-calculates the summary every time you scroll it into view. What leads you to believe that's happening? The summaries are not calculated until the summary cell is scrolled into view (or someone asks for the value) because that would be a waste of CPU cycles to calculate something no one needs. But once they are calculated once I can't see any reason to re-calculate them unless something in the column changed. 

I could be wrong about that as far as the built-in summary types are concerned, but I'm pretty sure that CalcManager summaries don't do that.