High Performance "Christmas Tree" DataGrids

The DataGrid component displays its dataProvider IList of "items" as grid rows.  Each GridColumn can be mapped to an arbitrary aspect of an item: it may display one item property, or several item properties, or the value of some computation based on one or more item properties, etc.

The DataGrid detects changes in its dataProvider by listening for CollectionEvents.  The CollectionEvents notify listeners about list structural changes, like items being added or removed, and they can also report that an item's value has been changed.  This is called a collection "update" event. What collection update events can not report is which grid columns were affected by an item's change.  In other words, CollectionEvents don't provide a way to notify the DataGrid that the contents of an individual grid cell have changed.

Applications can notify the DataGrid of changes to individual cells by calling the DataGrid invalidateCell() method.

invalidateCell(rowIndex:int, columnIndex:int)

The DataGrid's layout handles cell invalidations efficiently by only redisplaying the item renderer at the specified location, and only if it's actually visible. Multiple calls to invalidateCell() are batched up and deferred until the next layout phase, just like calls to invalidateSize() or invalidateDisplayList().

This example demonstrates the use of the DataGrid invalidateCell() method. Pressing the "Run" button starts a timer that updates DataGrid cells at the rate specified with the slider.

Here's the source code for the example.

This "Christmas Tree" DataGrid example displays a dataProvider with items whose substructure is constantly changing.  Each dataProvider item has one object valued property per column, and each of those properties has an object value that defines what's displayed in a single cell.  To keep things simple the column properties are just called "C0", "C1", ... and the value of each property is an object itself, with "color" and "index" properties, like {color:NN, index:NN}. So the data for the cell at rowIndex=10, columnIndex=5:

dataGrid.dataProvider.getItemAt(10)["C5"] => {color:0xFF6C0D, index:4}

The DataGrid has no way of knowing when the color,index data for a cell has been updated so the developer must call invalidateCell(rowIndex, columnIndex) to let the DataGrid know that the specified cell must be redisplayed.  When the "Run" button is toggled on, updateTimerHandler() method  below is called up to 64 times/second and each time it updates a single random cell's color and index properties and then calls invalidateCell().  Calling invalidateCell() only causes the (one) corresponding item renderer to redisplay, so long as doing so doesn't invalidate the corresponding row's height.  That can occur if variableRowHeight=true and if it does, the entire DataGrid is redisplayed.

The CPU load produced by applications like this one is only proportional to the update rate and the renderers' complexity, so long as the overall grid layout isn't affected by the cell updates.  Using fixed height rows with variableRowHeight="false" (the default), simple item renderers, and not dynamically changing column widths, are good ways to ensure that the CPU load is minimized.