flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Bradley <a...@kinesissoftware.com>
Subject Re: DataGrid perfomance
Date Tue, 17 Jan 2012 16:20:48 GMT
On 17/01/2012 10:02, Roland Zwaga wrote:
> > From what I heard the spark datagrid was a big improvement compared to the
> mx one,
> perhaps this can be used to further optimize the performance.
There is a considerable amount of work just to get a full set of necessary features into the
DataGrid - and that's without its current performance issues. Whether these performance issues

affect you as developer really depends on the domain you're working in - but it's a problem
large or dynamic data sources which may exclude it from many Enterprise applications.

Also, as David Arno references in another thread (Subject:Overly Large Classes), the DataGrid
composed of a small number of large classes and overriding particular features of the datagrid
be extremely difficult as the classes aren't decomposed into functional components i.e. you
need to override methods of the large DataGrid classes (DataGrid, Grid, GridLayout etc) while

needing to call the super... implementation methods of (SkinnableContainerBase, Group, LayoutBase

So is it worth finishing the Spark DataGrid and other large composite components when they
need such 
an overhaul? IMHO I think this would be time better spent on creating a new DataGrid from
based on principles of composition, and separation of concerns (I know we can do both but
... !).

The DataGrid component I wrote recently is based on functional composition and uses a pseudo

Spring-like context for injecting Factories and Configuration values into deeply nested component

parts. These components parts can be either display objects (renderers, indicators, scroll
headers etc), models (Row models, column models, data models, selection models etc) or Controller

objects(row and column drag controllers, layout controller, editor controller, scrolling strategies

etc). Currently, in KineticGrid, there are 59 different factories that can be overridden to

customise the grid and the grid functionality is still incomplete! These all interface-driven
have defaults, so are transparent to a developer unless specific functionality needs to be

Using a component-specific context provides a single point for access of factory providers,

configuration providers and component models that does not depend on the display list and
Manager for configuration - additionally most of the auto-binding between configuration and
instances can be performed automatically by the context and factory objects themselves. This

approach can provide performance advantages as separation of concerns allows plug-and-play
classes optimised for different domains. Decomposition also allows subsets of functionality
to be 
developed and shared either alongside, or within, the Flex Framework.

> A solid datagrid is an absolute must for the Flex SDK, but I'm sure a lot
> of people will
> be interested in lending a hand in that component. It ought to be the
> startcomponent
> of the entire framework I think, hehe.

A DataGrid component based on composition should automatically provide full List, Tree, Color

Picker, Date Chooser functionality so it's certainly a contender for starting component!

Despite compositional overhead, KineticGrid performs around 4-10 times quicker than Spark
grid in a 
dynamic scenario - if there's interest I can see about finding time to document the architecture.


Alex Bradley

View raw message