While on the topic of accessibility, does anyone know how this transfers over to a mobile environment?
On Tue, Jan 24, 2012 at 11:39 AM, Frank Pepermans <frankp...@hotmail.com>wrote: > 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<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 > -- Francis Altomare,
