1. Use Progressive Rendering
The Scheduler uses progressive rendering of key Scheduler elements. It will only render elements for the current viewport. Additional elements are rendered as the user scrolls.
- grid cells are always rendered progressively
- events are rendered progressively by default, can be turned off
- row headers are rendered progressively by default, can be turned off
It is essential to keep the progressive rendering enabled.
You can only turn it off for really small data sets to eliminate the slight delays before the elements are rendered during scrolling.
2. Debounce Rendering Performed during Scrolling
All UI updates performed during scrolling block the browser until they are completed. That's why the Scheduler uses delays that make the rendering asynchronous and debounce the extra requests. This introduces a short delay before the content is rendered it makes the scrolling smooth.
Properties
Use can use the the following properties to adjust the rendering delays in milliseconds:
- scrollDelayDynamic (default value: 500) - the delay before onScroll is called when dynamic event loading is enabled
- scrollDelayCells (default value: 0) - the delay before cells are rendered
- scrollDelayEvents (default value: 200) - the delay before events are rendered (when progressive event rendering is enabled)
- scrollDelayFloats (default value: 0) - the delay before the floating event overlays are updated
- scrollDelayRows (default value: 0) - the delay before row headers are rendered (only applicable when progressive row rendering is enabled); available since 2019.4.4075
Values
- 0 - synchronous execution: If you set the value of any of these properties to 0 they will be performed synchronously during scrolling, blocking the browser until the action is finished.
- 1-10 - asynchronous execution: Setting the value to 1 will make the execution asynchronous. Low values will not be enough to debounce the requests.
- 10+ - asynchronous execution with debouncing: The higher values you use the more requests will be debounced. This can improve performance for heavyweight views where longer time is needed to update the view.
Tuning
You can see that cells and event floats are rendered synchronously by default. This works well for desktop browsers but you may need to increase the scrollDelayCells value for slow devices.
If you see degraded scrolling performance try setting all values to a higher number (1000 ms). That will make the scrolling smooth but the delay will be noticeable. Try decreasing the values step by step until the rendering is fast enough but the scrolling speed is not affected.
3. Disable Row Header Width Auto-Fit
The row header width auto-fit feature is turned on by default. It calculates the row header width depending on the content and this can be very expensive, especially when displaying a lot of rows. When progressive row rendering is turned on, it will slow down the vertical scrolling.
If you can replace the dynamic width with a good static value it will improve performance significantly.
4. Keep the DOM Size Small
The Scheduler tries to minimize the DOM by rendering only the visible areas (progressive rendering).
However, the visible area can still contain too many DOM elements, especially if you customize the events and cells heavily or try to display a lot of small events at once.
Things you can try:
- Optimize the event and cell content (custom HTML and permanently-visible active areas) to use fewer DOM elements.
- Adjust the scale to display fewer items in the viewport.
- Adjust the cell and event dimensions (event height, cell width) to display fewer items in the viewport.
5. Minimize Real-Time Rendering Code
Check onBeforeCellRender event handler for inefficient code. This event is called once for every cell. The results of onBeforeCellRender are cached by default (beforeCellRenderCaching) but it can still affect rendering grid areas that were not visited before.
The onBeforeEventRender event is called during event loading and doesn't affect scrolling performance.