The first step in choosing a rendering model is to choose a paging model. This is because paging models are affected and limited by the type of rendering model used. The following table details these constraints.
| Rendering Model |
Available Paging Model |
Hierarchical |
|
Shallow/Deep |
- No paging
- 2-pass
- Chunked
- Paged
|
After you select a paging model, you can further refine the model by adjusting various tuners. Tuners provide greater control over how and when data is loaded. Note that tuners are not available for all models.
| Paging Model |
Available Tuners |
2-pass |
|
Chunked |
- Rows per Panel Number of rows in a panel.
|
Paged |
- Panel Pool Size Number of panels allowed on-screen before destroying the panel most distant from the current panel index.
- Rows per Panel Number of rows in a panel.
- Panel Queue Size Number of panels in the paint queue. As new panels are added to the queue to be painted, less-relevant panels in the queue are removed.
|
Stepped |
|
With the appropriate combination of rendering, paging, and tuning models, performance is greatly improved. For example, a four-column table of 250 rows renders with the best performance with these settings:
- Rendering Model: Deep
- Paging Model: Paged
- Tuners:
- Panel pool size: 5
- Rows per panel: 50
- Panel queue size: 3
Other factors might affect rendering performance, such as how often the instance is repainted, but this profile typically performs well.
For better performance, do not repaint the Matrix each time you add a column. For example, to add ten columns to a Matrix named matrix1, use this code:
var m = myServer.getJSXByName("matrix1");
for(var i=0;i<10;i++) {
m.load("some/url/for/the/column/prototype.xml",false);
}
m.repaint();
Note that passing false to the load command suppresses repainting.
Fine Tuning for Performance