Performance issue when Stripline changes size and position while scrolling

Attached is a sample. Run the sample, press the Zoom 3 Days button and drag the scrollbar (quite small) to scroll the chart back and forth the whole range. The two red striplines for the volume1 and volume2 chartrows constantly update themselves to fill the range from 0 to 50 on their yaxis. The performance is quite sluggish. Now, turn off the Update Striplines checkmark and scroll again. The striplines do not update, so they will move beyond their chartrows some times. The performance however is now better, about twice as responsive. 

The reason for this is because when the striplines change size and position via the SetStriplinesPosition sub, the CalculateVisibleRange sub in the CustomDateTimeCategoryXAxis class is called twice for no apparent reason. More important, the Update sub in the CustomFastStepLineBitmapSegment class is also called twice whereas when the checkmark is off, it's only called once. There should be no reason for it to be called twice.

How can the performance be improved while having the striplines update properly while scrolling?

Thank you.

Hi Tom, 

 

Greetings from Syncfusion.  

 

We have analyzed your query with provided sample and we were able to reproduce the reported problem with our end.  

 

However,  the stripline performance during scrolling has been improved by setting the dispatcher thread true when striplines are updated implicitly in axis range calculation. 

 

Note: This is set True when Stripline’s range is set in chart extensions implicitly but when set explicitly (Updating only Stripline's position) this should not be set True. 

 

Code Snippet 

 

Sample: http://www.syncfusion.com/downloads/support/forum/143455/ze/sfChartStriplinePerformance-176454951.zip 

 

Please let us know if you have any queries.  

 

Thanks,  

Muneesh Kumar G.  

 

Hi Tom, 

 

Thanks for the update. 

  

We are glad to know that the given solution works. Please let us know if you need any further assistance. 

 

Thanks,  

Muneesh Kumar G.