incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Buhler <>
Subject Re: Pushing Flex components thorough the GPU
Date Tue, 24 Jan 2012 16:29:02 GMT
I built a Flex website for the Federal government that was fully accessible
( I did a demo for Adobe of the Accessibility capabilities. I'm
glad to help with answering any accessibility questions.

On Tue, Jan 24, 2012 at 11:12 AM, Frank Pepermans <>wrote:

> 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?
> -----Original Message----- From: Roland Zwaga
> Sent: Tuesday, January 24, 2012 3:07 PM
> To:
> Subject: Re: Pushing Flex components thorough the GPU
>> Thanks Roland, that makes sense.
>> If I remember correctly Stage3D content is rendered behind the normal
>> DisplayList. This does allow you to mix Stage3D content with standard
>> components.
>> I guess when taking this into account it seems like item renderers would
>> not be the way to go.
>> What about narrowing down this use case and introducing a new component,
>> maybe something based off of the DataGroup? This may be able to allow us
>> to
>> get something "out the door" even with issues related to z-sorting and
>> accessibility.
>> I know currently these components rely heavily on the DisplayList, but
>> after looking at the Starling framework I really don't think there is
>> anything in place that would prevent this from happening.
> It sounds viable perhaps. I suggest you do some little tests do see if it
> is a workable
> avenue to explore. Using a POC component we could try and determine whether
> the
> accessibility limitations are of real issue or not. I'm not sure, but
> there's probably some kind
> of rules about what accepted accessibility is for a component, so at least
> we'll know what
> to look out for. Anyone here who can shed a light on this? I must say that
> I know next to nothing
> about it :) All I know is that its important, haha (sorry, ignorance
> shining through there...)
> I do believe that the combination of Stage3D and regaulr DisplayList based
> UI ought to
> be explored, because it seems like it could have great potential. But we
> will need to
> tread very carefully.
> cheers,
> Roland

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