incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Altomare <lost...@gmail.com>
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 <frankprms@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,

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