incubator-flex-dev mailing list archives

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message