incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank Pepermans" <>
Subject Re: Pushing Flex components thorough the GPU
Date Tue, 24 Jan 2012 16:39:07 GMT
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. (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
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.


View raw message