Indeed :)
Not very slightly off topic, I created a Spark component a while ago, which
utilizes pure Alchemy for all things related to layout,
performance is acceptable, and it can still be optimized much more by for
example using tinyTLF.
http://www.igindo.com/orgchart/index.html (click drag to move around,
randomly generated data)
Now I do agree Alchemy is not a good option, but cutting the fat on Flex and
maybe optimizing the compiler more would improve performance just the same
here the item renderers are just plain Flex ones
-----Original Message-----
From: Roland Zwaga
Sent: Tuesday, January 24, 2012 5:16 PM
To: flex-dev@incubator.apache.org
Subject: Re: Pushing Flex components thorough the GPU
Would be good to know exactly why Flex underperforms in areas such as item
renderers right now,
so much goes on when for example a grid is created and shown, that it is
hard to track down.
i.e. having tandem of the Flex layout framework plus Starling would still
be slow, especially the added code to manage an extra 3D display list.
optimizing the Flex innards, finding a good alternative to the TLF
components (a big hit for Spark based renderers), in future maybe adding
the Worker classes into Flex etc... might be enough to leave the stage3D
alone?
Good points Frank, I think the combination of Stage3D and DisplayList will
probably be used mostly in specialised components. There is plenty of
opportunity for optimization in the framework as it is. Perhaps TinyTLF
could prove a viable alternative for TLF for instance? I'm sure if the fat
is cut from the innards of the framework it should be able to perform
acceptably on devices as well.
Roland
