incubator-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
Spark 
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
for 
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
is 
composed of a small number of large classes and overriding particular features of the datagrid
can 
be extremely difficult as the classes aren't decomposed into functional components i.e. you
often 
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
etc).

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
scratch 
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
bars, 
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
and 
have defaults, so are transparent to a developer unless specific functionality needs to be
overidden.

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
Style 
Manager for configuration - additionally most of the auto-binding between configuration and
factory 
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
of 
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

-- 
Alex Bradley
-------------
http://www.kinesissoftware.com


Mime
View raw message