You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Carlos Rovira <ca...@apache.org> on 2013/07/10 18:38:12 UTC
About Statege3D in Flex
Hi,
from time to time people comes with the desire to see Flex running on
Stage3D. I would want to recopile all the state of the art info about this
topic and see if is possible and how much work it would require.
I know people like J.Campos did two attempts and get valious research from
that experience. There's things to get into account like accessibility.
Please could people share in this thread the things they know in order to
recopile all info? Is there some things to take into account that could
make Stage3D not possible for Flex? Could we overpass it and make it
possible? If it would be possible...it will brings real benefits?
If some work is done in this topic, I'd propose to make focused in this
particular thing and unlike FlexJS, here I will not try to break
UIComponent in small parts, or break compatibility. Even if it could be
possible to have a global flag like "enableStage3D" to make our apps run on
Stage3D if is true or remain in normal display layer, it could be great.
Thanks in advance for any insight regarding this topic.
Best
Carlos
Re: About Statege3D in Flex
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Wed, Jul 10, 2013 at 9:38 AM, Carlos Rovira <ca...@apache.org>wrote:
> Hi,
>
> from time to time people comes with the desire to see Flex running on
> Stage3D. I would want to recopile all the state of the art info about this
> topic and see if is possible and how much work it would require.
>
> I know people like J.Campos did two attempts and get valious research from
> that experience. There's things to get into account like accessibility.
>
> Please could people share in this thread the things they know in order to
> recopile all info? Is there some things to take into account that could
> make Stage3D not possible for Flex? Could we overpass it and make it
> possible? If it would be possible...it will brings real benefits?
>
> If some work is done in this topic, I'd propose to make focused in this
> particular thing and unlike FlexJS, here I will not try to break
> UIComponent in small parts, or break compatibility. Even if it could be
> possible to have a global flag like "enableStage3D" to make our apps run on
> Stage3D if is true or remain in normal display layer, it could be great.
>
> Thanks in advance for any insight regarding this topic.
>
> Best
>
> Carlos
>
Carlos,
Thanks for bringing this topic back up. I have been wanting to work with
FlexJS and hook up the view beads with Stage3D. I have a decent idea how
to go about it, but havent had a chance to write real code.
On the flip side, if we want to hook up the Vanilla Flex SDK with Stage3D,
I think the better option would be to make use of Starling. Here are a few
areas of concern and some ideas on how to tackle them.
*1) DisplayList*
Since Flex is closely tied with the concept of a display list, and since
Starling provides an abstraction layer on top of Stage3D with a concept of
display list, it will be easier to do it this way. This post by Tinic Uro
explains this problem in detail [1]
*Approaches to solve the problem:*
I think the best way to approach this would be to start with a simple class
tree (ex. FlexSprite > UIComponent > SkinnableComponent > ButtonBase >
Button) and tried to render it on the GPU. The crucial interface that
UIComponent implements is the IChildList.as. Figuring out how to map a
display list to Starling display list is key. [2]
*2) Vector vs. Bitmap rendering*
Once we figure out the displaylist paradigm, the next problem to solve
would be vector vs. bitmap drawing. Stage3D and Starling concentrates
mostly on bitmap rendering. It makes sense, because that is what the GPU
is best at. Whereas, most times using Flex, we want to draw vectors.
Resizable, vector (FXG, swf, etc.) based skins are used a lot in Flex.
So, figuring out drawing vectors using Stage3D is key for Flex.
*Approaches to solve the problem:*
Good news is that there has been some progress in this regard [3] I have
contacted the author of this project who has promised to open source the
code. Not sure when that is going to happen, though :-)
*3) Font rendering, TLF, etc.*
Once specific use case of drawing vectors would be rendering of fonts and
more complicated typography. Getting something as complicated as the TLF
library working on the GPU is going to take quite a bit of work.
*Approaches to solve the problem:*
Again, there has been some work in this area: [4] The Firetype project
attempts at rendering fonts via the GPU. Just getting the various aspects
of font rendering seems like a fun project :-)
*4) Accessibility*
Stage3D does not support any hooks to accessibility out of the box.
*Approaches to solve the problem:*
This is something we may have to solve using a combination of AS3 code and
use Externalnterface to handover accessibility to the browser. On mobile,
we may have to write some ANEs to deal with this. Of course, this approach
will cause performance issues. So, we may want to enable this via a
compiler switch.
Overall, this is a solvable problem, but it requires some disciplined
architecture and a lot of coding + coffee :-) As you mentioned, collecting
this kind of discussion summaries into a wiki page would be a great idea.
That said, jumping on the FlexJS bandwagon and use the redesign of Flex as
an opportunity to also render things using Stage3D is a great opportunity
for us. Afterall, if FlexJS can be rendered using HTML/Javascript, of
course we can figure out a way to render it using Flash's own Stage3D.
Every day FlexJS is progressing without us figuring out how to render it
on Stage3D is a great opportunity lost, IMO.
Thanks,
Om
[1] http://blog.kaourantin.net/?p=138
[2]
http://doc.starling-framework.org/core/starling/display/package-detail.html
[3] http://blog.bwhiting.co.uk/?p=423
[4] https://github.com/MaxDidIt/firetype
Re: About Statege3D in Flex
Posted by Nick Collins <nd...@gmail.com>.
What I am wondering is if we want to go the full Stage3D route, would it
not be beneficial to have the compiler do some of the heavy lifting ahead
of time? What I'm thinking is when you create a Flex project, you define a
set of target platforms. We already do this with AIR, such as defining iOS,
Android, retina or not, etc. Based on those defined platforms, the compiler
could optionally bake the skins to a texture atlas based on the target
platform of the current compilation cycle and it's display characteristics.
For example, I create a Flex Mobile project targeting iOS and Android. I
tell it that I am going to target both iPhone and iPad, and enable retina.
When I export the IPA, the precompiler couple optionally generate a texture
atlas for 160 dpi, 240 dpi, and 320 dpi skins and/or FXG graphics, and
generate some code into the main application class to use those images as
skins for the UI components, and upload the texture atlas to the GPU memory
space.
I am probably grossly oversimplifying the complexity of what would be
required to accomplish this, but it's how I sort of envision it working.
Nick
On Wed, Jul 24, 2013 at 7:31 AM, Arnoud Bos <ar...@artim-interactive.nl>wrote:
> Hi Avi,
>
> yeah i just played a bit with it and getting started takes some effort.
> As i understood they label it themselves as pre alpha now and heavy
> development is going on.
> So we have to wait and see what it will feel like in next stages. But the
> language features of playscript are great and
> using plain c# for native extensions seems way more productive than
> creating ANE's
>
> Anyway it made me feel good to compile a small test with both c# and
> actionscript3 code
> integrating seamlessly and run it on the iphone simulator :-) It has
> potential, but time will tell if it will succeed.
>
> But back to the main subject: Stage3D. My main point is that if flex
> graphics would be based on Stage3D it
> might be possible (with some serious work) to target other platforms than
> flash/air provides us with.
> (windows phone 8 for example). But i realize this will be an incredible
> amount of work and probably not realistic.
>
> best,
>
> Arnoud
>
>
>
>
>
> On 24-07-2013, at 11:57, Avi Kessner <ak...@gmail.com> wrote:
>
> > Other devs at my company who were tasked with looking at playscript
> > said it wasn't so good.
> > brought to you by the letters A, V, and I
> > and the number 47
> >
> >
> > On Wed, Jul 24, 2013 at 12:48 PM, Arnoud Bos
> > <ar...@artim-interactive.nl> wrote:
> >> Hi,
> >>
> >> Maybe it's also interesting to know that Zynga is creating a new
> language: Playscript.
> >> It's based on actionscript3 and C# and could be regarded as
> Actionscript 4 feature wise.
> >> The compiler is open source and based on mono.
> >>
> >> They also support compiling plain actionscript3 projects to run on mono
> with their
> >> compiler modifications. Or you can compile AOT it via Xamarin plugins
> to run native. So in effect this is
> >> removing the dependency on Air for mobile and desktop actionscript
> projects.
> >>
> >> Now the reason i mention it here is that they plan to support
> Stage3D/Starling/Away3D/Feathers
> >> but not the displaylist. So in theory flex, if using stage3d for
> rendering, could run on mono
> >> or native without adobe compilers involved if i understand correctly.
> >>
> >> To make this work there's a few things needed:
> >> * falcon should output actionscript3 / playscript (for mxml support)
> >> * flex should replace the displaylist with stage3d (maybe starling)
> >> * the zynga compiler needs to mature
> >>
> >> Seems like a really big effort is needed to pull this off, but i
> thought i'd mention it for completeness of the discussion.
> >>
> >> Anyway for people interested here's the link:
> >> http://playscript.github.io
> >>
> >> best, Arnoud
> >>
> >>
> >>
> >>
> >> On 10-07-2013, at 18:38, Carlos Rovira <ca...@apache.org> wrote:
> >>
> >>> Hi,
> >>>
> >>> from time to time people comes with the desire to see Flex running on
> >>> Stage3D. I would want to recopile all the state of the art info about
> this
> >>> topic and see if is possible and how much work it would require.
> >>>
> >>> I know people like J.Campos did two attempts and get valious research
> from
> >>> that experience. There's things to get into account like accessibility.
> >>>
> >>> Please could people share in this thread the things they know in order
> to
> >>> recopile all info? Is there some things to take into account that could
> >>> make Stage3D not possible for Flex? Could we overpass it and make it
> >>> possible? If it would be possible...it will brings real benefits?
> >>>
> >>> If some work is done in this topic, I'd propose to make focused in this
> >>> particular thing and unlike FlexJS, here I will not try to break
> >>> UIComponent in small parts, or break compatibility. Even if it could
> be
> >>> possible to have a global flag like "enableStage3D" to make our apps
> run on
> >>> Stage3D if is true or remain in normal display layer, it could be
> great.
> >>>
> >>> Thanks in advance for any insight regarding this topic.
> >>>
> >>> Best
> >>>
> >>> Carlos
> >>
> >>
> >>
> >>
> >>
> >>
> >>
>
> Met vriendelijke groet,
>
> Arnoud Bos
> Artim interactive
>
> E arnoud@artim-interactive.nl
> W www.artim-interactive.nl
> T +31 6 246 40 216
> A Elisabeth Wolffstraat 77-3
> 1053TT Amsterdam
>
>
>
>
>
>
Re: About Statege3D in Flex
Posted by Arnoud Bos <ar...@artim-interactive.nl>.
Hi Avi,
yeah i just played a bit with it and getting started takes some effort.
As i understood they label it themselves as pre alpha now and heavy development is going on.
So we have to wait and see what it will feel like in next stages. But the language features of playscript are great and
using plain c# for native extensions seems way more productive than creating ANE's
Anyway it made me feel good to compile a small test with both c# and actionscript3 code
integrating seamlessly and run it on the iphone simulator :-) It has potential, but time will tell if it will succeed.
But back to the main subject: Stage3D. My main point is that if flex graphics would be based on Stage3D it
might be possible (with some serious work) to target other platforms than flash/air provides us with.
(windows phone 8 for example). But i realize this will be an incredible amount of work and probably not realistic.
best,
Arnoud
On 24-07-2013, at 11:57, Avi Kessner <ak...@gmail.com> wrote:
> Other devs at my company who were tasked with looking at playscript
> said it wasn't so good.
> brought to you by the letters A, V, and I
> and the number 47
>
>
> On Wed, Jul 24, 2013 at 12:48 PM, Arnoud Bos
> <ar...@artim-interactive.nl> wrote:
>> Hi,
>>
>> Maybe it's also interesting to know that Zynga is creating a new language: Playscript.
>> It's based on actionscript3 and C# and could be regarded as Actionscript 4 feature wise.
>> The compiler is open source and based on mono.
>>
>> They also support compiling plain actionscript3 projects to run on mono with their
>> compiler modifications. Or you can compile AOT it via Xamarin plugins to run native. So in effect this is
>> removing the dependency on Air for mobile and desktop actionscript projects.
>>
>> Now the reason i mention it here is that they plan to support Stage3D/Starling/Away3D/Feathers
>> but not the displaylist. So in theory flex, if using stage3d for rendering, could run on mono
>> or native without adobe compilers involved if i understand correctly.
>>
>> To make this work there's a few things needed:
>> * falcon should output actionscript3 / playscript (for mxml support)
>> * flex should replace the displaylist with stage3d (maybe starling)
>> * the zynga compiler needs to mature
>>
>> Seems like a really big effort is needed to pull this off, but i thought i'd mention it for completeness of the discussion.
>>
>> Anyway for people interested here's the link:
>> http://playscript.github.io
>>
>> best, Arnoud
>>
>>
>>
>>
>> On 10-07-2013, at 18:38, Carlos Rovira <ca...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> from time to time people comes with the desire to see Flex running on
>>> Stage3D. I would want to recopile all the state of the art info about this
>>> topic and see if is possible and how much work it would require.
>>>
>>> I know people like J.Campos did two attempts and get valious research from
>>> that experience. There's things to get into account like accessibility.
>>>
>>> Please could people share in this thread the things they know in order to
>>> recopile all info? Is there some things to take into account that could
>>> make Stage3D not possible for Flex? Could we overpass it and make it
>>> possible? If it would be possible...it will brings real benefits?
>>>
>>> If some work is done in this topic, I'd propose to make focused in this
>>> particular thing and unlike FlexJS, here I will not try to break
>>> UIComponent in small parts, or break compatibility. Even if it could be
>>> possible to have a global flag like "enableStage3D" to make our apps run on
>>> Stage3D if is true or remain in normal display layer, it could be great.
>>>
>>> Thanks in advance for any insight regarding this topic.
>>>
>>> Best
>>>
>>> Carlos
>>
>>
>>
>>
>>
>>
>>
Met vriendelijke groet,
Arnoud Bos
Artim interactive
E arnoud@artim-interactive.nl
W www.artim-interactive.nl
T +31 6 246 40 216
A Elisabeth Wolffstraat 77-3
1053TT Amsterdam
Re: About Statege3D in Flex
Posted by Avi Kessner <ak...@gmail.com>.
Other devs at my company who were tasked with looking at playscript
said it wasn't so good.
brought to you by the letters A, V, and I
and the number 47
On Wed, Jul 24, 2013 at 12:48 PM, Arnoud Bos
<ar...@artim-interactive.nl> wrote:
> Hi,
>
> Maybe it's also interesting to know that Zynga is creating a new language: Playscript.
> It's based on actionscript3 and C# and could be regarded as Actionscript 4 feature wise.
> The compiler is open source and based on mono.
>
> They also support compiling plain actionscript3 projects to run on mono with their
> compiler modifications. Or you can compile AOT it via Xamarin plugins to run native. So in effect this is
> removing the dependency on Air for mobile and desktop actionscript projects.
>
> Now the reason i mention it here is that they plan to support Stage3D/Starling/Away3D/Feathers
> but not the displaylist. So in theory flex, if using stage3d for rendering, could run on mono
> or native without adobe compilers involved if i understand correctly.
>
> To make this work there's a few things needed:
> * falcon should output actionscript3 / playscript (for mxml support)
> * flex should replace the displaylist with stage3d (maybe starling)
> * the zynga compiler needs to mature
>
> Seems like a really big effort is needed to pull this off, but i thought i'd mention it for completeness of the discussion.
>
> Anyway for people interested here's the link:
> http://playscript.github.io
>
> best, Arnoud
>
>
>
>
> On 10-07-2013, at 18:38, Carlos Rovira <ca...@apache.org> wrote:
>
>> Hi,
>>
>> from time to time people comes with the desire to see Flex running on
>> Stage3D. I would want to recopile all the state of the art info about this
>> topic and see if is possible and how much work it would require.
>>
>> I know people like J.Campos did two attempts and get valious research from
>> that experience. There's things to get into account like accessibility.
>>
>> Please could people share in this thread the things they know in order to
>> recopile all info? Is there some things to take into account that could
>> make Stage3D not possible for Flex? Could we overpass it and make it
>> possible? If it would be possible...it will brings real benefits?
>>
>> If some work is done in this topic, I'd propose to make focused in this
>> particular thing and unlike FlexJS, here I will not try to break
>> UIComponent in small parts, or break compatibility. Even if it could be
>> possible to have a global flag like "enableStage3D" to make our apps run on
>> Stage3D if is true or remain in normal display layer, it could be great.
>>
>> Thanks in advance for any insight regarding this topic.
>>
>> Best
>>
>> Carlos
>
>
>
>
>
>
>
Re: About Statege3D in Flex
Posted by Arnoud Bos <ar...@artim-interactive.nl>.
Hi,
Maybe it's also interesting to know that Zynga is creating a new language: Playscript.
It's based on actionscript3 and C# and could be regarded as Actionscript 4 feature wise.
The compiler is open source and based on mono.
They also support compiling plain actionscript3 projects to run on mono with their
compiler modifications. Or you can compile AOT it via Xamarin plugins to run native. So in effect this is
removing the dependency on Air for mobile and desktop actionscript projects.
Now the reason i mention it here is that they plan to support Stage3D/Starling/Away3D/Feathers
but not the displaylist. So in theory flex, if using stage3d for rendering, could run on mono
or native without adobe compilers involved if i understand correctly.
To make this work there's a few things needed:
* falcon should output actionscript3 / playscript (for mxml support)
* flex should replace the displaylist with stage3d (maybe starling)
* the zynga compiler needs to mature
Seems like a really big effort is needed to pull this off, but i thought i'd mention it for completeness of the discussion.
Anyway for people interested here's the link:
http://playscript.github.io
best, Arnoud
On 10-07-2013, at 18:38, Carlos Rovira <ca...@apache.org> wrote:
> Hi,
>
> from time to time people comes with the desire to see Flex running on
> Stage3D. I would want to recopile all the state of the art info about this
> topic and see if is possible and how much work it would require.
>
> I know people like J.Campos did two attempts and get valious research from
> that experience. There's things to get into account like accessibility.
>
> Please could people share in this thread the things they know in order to
> recopile all info? Is there some things to take into account that could
> make Stage3D not possible for Flex? Could we overpass it and make it
> possible? If it would be possible...it will brings real benefits?
>
> If some work is done in this topic, I'd propose to make focused in this
> particular thing and unlike FlexJS, here I will not try to break
> UIComponent in small parts, or break compatibility. Even if it could be
> possible to have a global flag like "enableStage3D" to make our apps run on
> Stage3D if is true or remain in normal display layer, it could be great.
>
> Thanks in advance for any insight regarding this topic.
>
> Best
>
> Carlos
Re: About Statege3D in Flex
Posted by Gary Young <fl...@gmail.com>.
I just want to say there's no need to redesign Flex framework, Spark
skinning, two way bindings and Mxml interface are not only still on the
cutting edge but also need more time to be really adapted, what need to
change is the implementation, Flex has too many legacy code to maintain
back compatibilities, if Flex can give rid of Flex 2,3 code, it will be
more efficient and easy to use. -Gary
On Wed, Jul 10, 2013 at 2:02 PM, DarkStone <Da...@163.com> wrote:
> Hi Carlos,
>
> The benefit of enabling Stage3D for Flex would be:
>
> 1. Much better performance on mobile devices.
>
> 2. Be able to develop Real 3D Apps and Games.
>
> 3. Making Flex the best cross platform native app developing SDK.
>
> In fact you can use Stage3D directly in Flex Applications, Stage3D layers
> are below the Flex Application layer. But you can not take any advantages
> of Flex like MXML, Bindings, FXG, CSS etc. Cuz the current Flex is not
> design for the Stage3D kind of things.
>
> In order to enable full support of Stage3D for Flex, it requires redesign
> Flex Framework from the ground up. Cuz Stage3D is about GPU rather than
> CPU, and the GPU Programming is quite different than CPU, you need to
> understand and deal with vertex, mesh, shader, texture, AGAL...
>
> However there are still some feasible ways to enable Stage3D for Flex,
> here is one I thought of:
>
> Redesign the Flex Framework by building it on top of the Starling
> Framework, this approach can reserve most of the Flex API names, for
> example UIComponent Class, FlexSprite Class etc. They are still the same
> class names and package names, but they need to extends the Starling Sprite
> Class instead of the original one. And of course, a simple extends Starling
> Sprite Class ain't gonna work, we will have to reimplement all of the
> subclasses, yes it's hell.
>
> Anyway, unless someone can invest a million dollars on this, I don't think
> full Stage3D support for Flex will become reality in these years, although
> personally I want this so bad.
>
>
> Sent from DarkStone's iPhone
>
> 在 2013-7-11，0:38，Carlos Rovira <ca...@apache.org> 写道：
>
> > Hi,
> >
> > from time to time people comes with the desire to see Flex running on
> > Stage3D. I would want to recopile all the state of the art info about
> this
> > topic and see if is possible and how much work it would require.
> >
> > I know people like J.Campos did two attempts and get valious research
> from
> > that experience. There's things to get into account like accessibility.
> >
> > Please could people share in this thread the things they know in order to
> > recopile all info? Is there some things to take into account that could
> > make Stage3D not possible for Flex? Could we overpass it and make it
> > possible? If it would be possible...it will brings real benefits?
> >
> > If some work is done in this topic, I'd propose to make focused in this
> > particular thing and unlike FlexJS, here I will not try to break
> > UIComponent in small parts, or break compatibility. Even if it could be
> > possible to have a global flag like "enableStage3D" to make our apps run
> on
> > Stage3D if is true or remain in normal display layer, it could be great.
> >
> > Thanks in advance for any insight regarding this topic.
> >
> > Best
> >
> > Carlos
> >
>
>
Re: About Statege3D in Flex
Posted by Thomas Wright <tw...@yesco.com>.
heh - nothing to do with this thread, but as I glanced to my inbox, I
thought the from field read, "Kevin Mitnick"
had to make a double take. Couldn't think of any really valid reason why
Mitnick would've been sending an email my way :P
anyway ... don't let me interrupt the thread :D
On Fri, Jul 19, 2013 at 3:08 PM, Nick Collins <nd...@gmail.com> wrote:
> Not holding my breath for that one, Kevin... though I agree it would be
> very cool!
>
>
> On Fri, Jul 19, 2013 at 3:57 PM, Kevin Newman <Ca...@unfocus.com>
> wrote:
>
> > The higher level Flex Framework doesn't really need to know about all
> > the AGAL, texture stuff, etc. It's possible (as Gnome2D has shown) to
> > basically just make a blitting surface, and treat it like a BitmapData
> > object that has high initial latency, with screaming runtime blitting,
> > for rendering (as an extreme over simplification).
> >
> > The trick with the GPU is the lack of shared address space between CPU
> > and GPU, which creates a huge bottleneck for moving image data from CPU
> > to GPU. That's the primary pain point. Anyone implementing a high level
> > API on GPU, mostly needs to target that pain point - keep GPU uploads
> > and invalidation low, and you'll be fine (as long as your GPU code is
> > stable, handles batching well, and doesn't change the GPU state too
> much).
> >
> > On iOS, they use a metaphor of "layer backing" to help keep the pain
> > point clear as they are designing, and communicating that to users of
> > the their GPU powered APIs. WebKit uses that in some docs too, though
> > it's less clear when you are activating layer backing, and Adobe tried
> > to communicate that when they were doing GPU-Blend (something marked
> > with cacheAsBitmapMatrix became "layer backed") with earlier builds of
> > PFI, though they eventually switched to a GPU tessellation method of
> > rendering.
> >
> > Related: What's really more exciting than I think the lack of buzz
> > indicates, is AMD's new shared address space for CPU and GPU (in the
> > chip shipping in both XBox One and PS4). That's going to completely
> > remove this primary bottleneck, and make GPU programming a first class
> > citizen, able to seamlessly share data between CPU and GPU - very very
> > exciting. Hopefully that'll work it's way over to mobile computing in
> > short order, where I think it'll have much more benefit (at least until
> > Intel eventually ships a compatible extension in x86 ecosystems).
> >
> > Kevin N.
> >
> >
> >
> > On 7/10/13 2:02 PM, DarkStone wrote:
> > > Hi Carlos,
> > >
> > > The benefit of enabling Stage3D for Flex would be:
> > >
> > > 1. Much better performance on mobile devices.
> > >
> > > 2. Be able to develop Real 3D Apps and Games.
> > >
> > > 3. Making Flex the best cross platform native app developing SDK.
> > >
> > > In fact you can use Stage3D directly in Flex Applications, Stage3D
> > layers are below the Flex Application layer. But you can not take any
> > advantages of Flex like MXML, Bindings, FXG, CSS etc. Cuz the current
> Flex
> > is not design for the Stage3D kind of things.
> > >
> > > In order to enable full support of Stage3D for Flex, it requires
> > redesign Flex Framework from the ground up. Cuz Stage3D is about GPU
> rather
> > than CPU, and the GPU Programming is quite different than CPU, you need
> to
> > understand and deal with vertex, mesh, shader, texture, AGAL...
> > >
> > > However there are still some feasible ways to enable Stage3D for Flex,
> > here is one I thought of:
> > >
> > > Redesign the Flex Framework by building it on top of the Starling
> > Framework, this approach can reserve most of the Flex API names, for
> > example UIComponent Class, FlexSprite Class etc. They are still the same
> > class names and package names, but they need to extends the Starling
> Sprite
> > Class instead of the original one. And of course, a simple extends
> Starling
> > Sprite Class ain't gonna work, we will have to reimplement all of the
> > subclasses, yes it's hell.
> > >
> > > Anyway, unless someone can invest a million dollars on this, I don't
> > think full Stage3D support for Flex will become reality in these years,
> > although personally I want this so bad.
> > >
> > >
> > > Sent from DarkStone's iPhone
> > >
> > > 在 2013-7-11，0:38，Carlos Rovira <ca...@apache.org> 写道：
> > >
> > >> Hi,
> > >>
> > >> from time to time people comes with the desire to see Flex running on
> > >> Stage3D. I would want to recopile all the state of the art info about
> > this
> > >> topic and see if is possible and how much work it would require.
> > >>
> > >> I know people like J.Campos did two attempts and get valious research
> > from
> > >> that experience. There's things to get into account like
> accessibility.
> > >>
> > >> Please could people share in this thread the things they know in order
> > to
> > >> recopile all info? Is there some things to take into account that
> could
> > >> make Stage3D not possible for Flex? Could we overpass it and make it
> > >> possible? If it would be possible...it will brings real benefits?
> > >>
> > >> If some work is done in this topic, I'd propose to make focused in
> this
> > >> particular thing and unlike FlexJS, here I will not try to break
> > >> UIComponent in small parts, or break compatibility. Even if it could
> be
> > >> possible to have a global flag like "enableStage3D" to make our apps
> > run on
> > >> Stage3D if is true or remain in normal display layer, it could be
> great.
> > >>
> > >> Thanks in advance for any insight regarding this topic.
> > >>
> > >> Best
> > >>
> > >> Carlos
> > >>
> >
> >
>
--
*Thomas Wright*
Software Engineer
Extension: 1054
Office: [801] 464.4600
Corporate Division
twright@yesco.com
Re: About Statege3D in Flex
Posted by Nick Collins <nd...@gmail.com>.
Not holding my breath for that one, Kevin... though I agree it would be
very cool!
On Fri, Jul 19, 2013 at 3:57 PM, Kevin Newman <Ca...@unfocus.com> wrote:
> The higher level Flex Framework doesn't really need to know about all
> the AGAL, texture stuff, etc. It's possible (as Gnome2D has shown) to
> basically just make a blitting surface, and treat it like a BitmapData
> object that has high initial latency, with screaming runtime blitting,
> for rendering (as an extreme over simplification).
>
> The trick with the GPU is the lack of shared address space between CPU
> and GPU, which creates a huge bottleneck for moving image data from CPU
> to GPU. That's the primary pain point. Anyone implementing a high level
> API on GPU, mostly needs to target that pain point - keep GPU uploads
> and invalidation low, and you'll be fine (as long as your GPU code is
> stable, handles batching well, and doesn't change the GPU state too much).
>
> On iOS, they use a metaphor of "layer backing" to help keep the pain
> point clear as they are designing, and communicating that to users of
> the their GPU powered APIs. WebKit uses that in some docs too, though
> it's less clear when you are activating layer backing, and Adobe tried
> to communicate that when they were doing GPU-Blend (something marked
> with cacheAsBitmapMatrix became "layer backed") with earlier builds of
> PFI, though they eventually switched to a GPU tessellation method of
> rendering.
>
> Related: What's really more exciting than I think the lack of buzz
> indicates, is AMD's new shared address space for CPU and GPU (in the
> chip shipping in both XBox One and PS4). That's going to completely
> remove this primary bottleneck, and make GPU programming a first class
> citizen, able to seamlessly share data between CPU and GPU - very very
> exciting. Hopefully that'll work it's way over to mobile computing in
> short order, where I think it'll have much more benefit (at least until
> Intel eventually ships a compatible extension in x86 ecosystems).
>
> Kevin N.
>
>
>
> On 7/10/13 2:02 PM, DarkStone wrote:
> > Hi Carlos,
> >
> > The benefit of enabling Stage3D for Flex would be:
> >
> > 1. Much better performance on mobile devices.
> >
> > 2. Be able to develop Real 3D Apps and Games.
> >
> > 3. Making Flex the best cross platform native app developing SDK.
> >
> > In fact you can use Stage3D directly in Flex Applications, Stage3D
> layers are below the Flex Application layer. But you can not take any
> advantages of Flex like MXML, Bindings, FXG, CSS etc. Cuz the current Flex
> is not design for the Stage3D kind of things.
> >
> > In order to enable full support of Stage3D for Flex, it requires
> redesign Flex Framework from the ground up. Cuz Stage3D is about GPU rather
> than CPU, and the GPU Programming is quite different than CPU, you need to
> understand and deal with vertex, mesh, shader, texture, AGAL...
> >
> > However there are still some feasible ways to enable Stage3D for Flex,
> here is one I thought of:
> >
> > Redesign the Flex Framework by building it on top of the Starling
> Framework, this approach can reserve most of the Flex API names, for
> example UIComponent Class, FlexSprite Class etc. They are still the same
> class names and package names, but they need to extends the Starling Sprite
> Class instead of the original one. And of course, a simple extends Starling
> Sprite Class ain't gonna work, we will have to reimplement all of the
> subclasses, yes it's hell.
> >
> > Anyway, unless someone can invest a million dollars on this, I don't
> think full Stage3D support for Flex will become reality in these years,
> although personally I want this so bad.
> >
> >
> > Sent from DarkStone's iPhone
> >
> > 在 2013-7-11，0:38，Carlos Rovira <ca...@apache.org> 写道：
> >
> >> Hi,
> >>
> >> from time to time people comes with the desire to see Flex running on
> >> Stage3D. I would want to recopile all the state of the art info about
> this
> >> topic and see if is possible and how much work it would require.
> >>
> >> I know people like J.Campos did two attempts and get valious research
> from
> >> that experience. There's things to get into account like accessibility.
> >>
> >> Please could people share in this thread the things they know in order
> to
> >> recopile all info? Is there some things to take into account that could
> >> make Stage3D not possible for Flex? Could we overpass it and make it
> >> possible? If it would be possible...it will brings real benefits?
> >>
> >> If some work is done in this topic, I'd propose to make focused in this
> >> particular thing and unlike FlexJS, here I will not try to break
> >> UIComponent in small parts, or break compatibility. Even if it could be
> >> possible to have a global flag like "enableStage3D" to make our apps
> run on
> >> Stage3D if is true or remain in normal display layer, it could be great.
> >>
> >> Thanks in advance for any insight regarding this topic.
> >>
> >> Best
> >>
> >> Carlos
> >>
>
>
Re: About Statege3D in Flex
Posted by Kevin Newman <Ca...@unFocus.com>.
APU was used before they released hUMA (heterogeneous uniform memory
access). APU really just means the CPU and GPU are on the same die. The
idea was always to bring the two together more tightly, but earlier APUs
still partition system memory between CPU and GPU, and when you want to
move data from CPU to GPU, you have to copy it all - which is indeed
fast in an APU.
The thing that hUMA changes (which is in XBox One and PS3 - but I don't
think is in any shipping mobile hardware yet, except AMD's Kabini) is
when you want to change from working on data from CPU to GPU (or back
again) you only need to send a pointer to where the data already exists
in memory - there is no more partition, and no more copy. That's
entirely different, and the biggest impact it will have is that it'll
make life MUCH easier for programmers (at least I hope so).
That is, unless I've misunderstood something (some of the DirectX 11.2
stuff has confused me a bit - but that might just be on the Intel side -
I'm still reading up).
Kevin N.
On 7/20/13 10:01 PM, jude wrote:
> I thought that mobile devices were already eliminating this bottleneck
> through the use of the APU? Is this the same as what's going on in PS4 and
> XBox One? The first search result for APU actually mentions Flash in the
> video,http://www.geek.com/chips/what-is-an-apu-1304427/
Re: About Statege3D in Flex
Posted by jude <fl...@gmail.com>.
I thought that mobile devices were already eliminating this bottleneck
through the use of the APU? Is this the same as what's going on in PS4 and
XBox One? The first search result for APU actually mentions Flash in the
video, http://www.geek.com/chips/what-is-an-apu-1304427/
On Fri, Jul 19, 2013 at 3:57 PM, Kevin Newman <Ca...@unfocus.com> wrote:
> The higher level Flex Framework doesn't really need to know about all
> the AGAL, texture stuff, etc. It's possible (as Gnome2D has shown) to
> basically just make a blitting surface, and treat it like a BitmapData
> object that has high initial latency, with screaming runtime blitting,
> for rendering (as an extreme over simplification).
>
> The trick with the GPU is the lack of shared address space between CPU
> and GPU, which creates a huge bottleneck for moving image data from CPU
> to GPU. That's the primary pain point. Anyone implementing a high level
> API on GPU, mostly needs to target that pain point - keep GPU uploads
> and invalidation low, and you'll be fine (as long as your GPU code is
> stable, handles batching well, and doesn't change the GPU state too much).
>
> On iOS, they use a metaphor of "layer backing" to help keep the pain
> point clear as they are designing, and communicating that to users of
> the their GPU powered APIs. WebKit uses that in some docs too, though
> it's less clear when you are activating layer backing, and Adobe tried
> to communicate that when they were doing GPU-Blend (something marked
> with cacheAsBitmapMatrix became "layer backed") with earlier builds of
> PFI, though they eventually switched to a GPU tessellation method of
> rendering.
>
> Related: What's really more exciting than I think the lack of buzz
> indicates, is AMD's new shared address space for CPU and GPU (in the
> chip shipping in both XBox One and PS4). That's going to completely
> remove this primary bottleneck, and make GPU programming a first class
> citizen, able to seamlessly share data between CPU and GPU - very very
> exciting. Hopefully that'll work it's way over to mobile computing in
> short order, where I think it'll have much more benefit (at least until
> Intel eventually ships a compatible extension in x86 ecosystems).
>
> Kevin N.
>
>
>
> On 7/10/13 2:02 PM, DarkStone wrote:
> > Hi Carlos,
> >
> > The benefit of enabling Stage3D for Flex would be:
> >
> > 1. Much better performance on mobile devices.
> >
> > 2. Be able to develop Real 3D Apps and Games.
> >
> > 3. Making Flex the best cross platform native app developing SDK.
> >
> > In fact you can use Stage3D directly in Flex Applications, Stage3D
> layers are below the Flex Application layer. But you can not take any
> advantages of Flex like MXML, Bindings, FXG, CSS etc. Cuz the current Flex
> is not design for the Stage3D kind of things.
> >
> > In order to enable full support of Stage3D for Flex, it requires
> redesign Flex Framework from the ground up. Cuz Stage3D is about GPU rather
> than CPU, and the GPU Programming is quite different than CPU, you need to
> understand and deal with vertex, mesh, shader, texture, AGAL...
> >
> > However there are still some feasible ways to enable Stage3D for Flex,
> here is one I thought of:
> >
> > Redesign the Flex Framework by building it on top of the Starling
> Framework, this approach can reserve most of the Flex API names, for
> example UIComponent Class, FlexSprite Class etc. They are still the same
> class names and package names, but they need to extends the Starling Sprite
> Class instead of the original one. And of course, a simple extends Starling
> Sprite Class ain't gonna work, we will have to reimplement all of the
> subclasses, yes it's hell.
> >
> > Anyway, unless someone can invest a million dollars on this, I don't
> think full Stage3D support for Flex will become reality in these years,
> although personally I want this so bad.
> >
> >
> > Sent from DarkStone's iPhone
> >
> > 在 2013-7-11，0:38，Carlos Rovira <ca...@apache.org> 写道：
> >
> >> Hi,
> >>
> >> from time to time people comes with the desire to see Flex running on
> >> Stage3D. I would want to recopile all the state of the art info about
> this
> >> topic and see if is possible and how much work it would require.
> >>
> >> I know people like J.Campos did two attempts and get valious research
> from
> >> that experience. There's things to get into account like accessibility.
> >>
> >> Please could people share in this thread the things they know in order
> to
> >> recopile all info? Is there some things to take into account that could
> >> make Stage3D not possible for Flex? Could we overpass it and make it
> >> possible? If it would be possible...it will brings real benefits?
> >>
> >> If some work is done in this topic, I'd propose to make focused in this
> >> particular thing and unlike FlexJS, here I will not try to break
> >> UIComponent in small parts, or break compatibility. Even if it could be
> >> possible to have a global flag like "enableStage3D" to make our apps
> run on
> >> Stage3D if is true or remain in normal display layer, it could be great.
> >>
> >> Thanks in advance for any insight regarding this topic.
> >>
> >> Best
> >>
> >> Carlos
> >>
>
>
Re: About Statege3D in Flex
Posted by Kevin Newman <Ca...@unFocus.com>.
The higher level Flex Framework doesn't really need to know about all
the AGAL, texture stuff, etc. It's possible (as Gnome2D has shown) to
basically just make a blitting surface, and treat it like a BitmapData
object that has high initial latency, with screaming runtime blitting,
for rendering (as an extreme over simplification).
The trick with the GPU is the lack of shared address space between CPU
and GPU, which creates a huge bottleneck for moving image data from CPU
to GPU. That's the primary pain point. Anyone implementing a high level
API on GPU, mostly needs to target that pain point - keep GPU uploads
and invalidation low, and you'll be fine (as long as your GPU code is
stable, handles batching well, and doesn't change the GPU state too much).
On iOS, they use a metaphor of "layer backing" to help keep the pain
point clear as they are designing, and communicating that to users of
the their GPU powered APIs. WebKit uses that in some docs too, though
it's less clear when you are activating layer backing, and Adobe tried
to communicate that when they were doing GPU-Blend (something marked
with cacheAsBitmapMatrix became "layer backed") with earlier builds of
PFI, though they eventually switched to a GPU tessellation method of
rendering.
Related: What's really more exciting than I think the lack of buzz
indicates, is AMD's new shared address space for CPU and GPU (in the
chip shipping in both XBox One and PS4). That's going to completely
remove this primary bottleneck, and make GPU programming a first class
citizen, able to seamlessly share data between CPU and GPU - very very
exciting. Hopefully that'll work it's way over to mobile computing in
short order, where I think it'll have much more benefit (at least until
Intel eventually ships a compatible extension in x86 ecosystems).
Kevin N.
On 7/10/13 2:02 PM, DarkStone wrote:
> Hi Carlos,
>
> The benefit of enabling Stage3D for Flex would be:
>
> 1. Much better performance on mobile devices.
>
> 2. Be able to develop Real 3D Apps and Games.
>
> 3. Making Flex the best cross platform native app developing SDK.
>
> In fact you can use Stage3D directly in Flex Applications, Stage3D layers are below the Flex Application layer. But you can not take any advantages of Flex like MXML, Bindings, FXG, CSS etc. Cuz the current Flex is not design for the Stage3D kind of things.
>
> In order to enable full support of Stage3D for Flex, it requires redesign Flex Framework from the ground up. Cuz Stage3D is about GPU rather than CPU, and the GPU Programming is quite different than CPU, you need to understand and deal with vertex, mesh, shader, texture, AGAL...
>
> However there are still some feasible ways to enable Stage3D for Flex, here is one I thought of:
>
> Redesign the Flex Framework by building it on top of the Starling Framework, this approach can reserve most of the Flex API names, for example UIComponent Class, FlexSprite Class etc. They are still the same class names and package names, but they need to extends the Starling Sprite Class instead of the original one. And of course, a simple extends Starling Sprite Class ain't gonna work, we will have to reimplement all of the subclasses, yes it's hell.
>
> Anyway, unless someone can invest a million dollars on this, I don't think full Stage3D support for Flex will become reality in these years, although personally I want this so bad.
>
>
> Sent from DarkStone's iPhone
>
> 在 2013-7-11，0:38，Carlos Rovira <ca...@apache.org> 写道：
>
>> Hi,
>>
>> from time to time people comes with the desire to see Flex running on
>> Stage3D. I would want to recopile all the state of the art info about this
>> topic and see if is possible and how much work it would require.
>>
>> I know people like J.Campos did two attempts and get valious research from
>> that experience. There's things to get into account like accessibility.
>>
>> Please could people share in this thread the things they know in order to
>> recopile all info? Is there some things to take into account that could
>> make Stage3D not possible for Flex? Could we overpass it and make it
>> possible? If it would be possible...it will brings real benefits?
>>
>> If some work is done in this topic, I'd propose to make focused in this
>> particular thing and unlike FlexJS, here I will not try to break
>> UIComponent in small parts, or break compatibility. Even if it could be
>> possible to have a global flag like "enableStage3D" to make our apps run on
>> Stage3D if is true or remain in normal display layer, it could be great.
>>
>> Thanks in advance for any insight regarding this topic.
>>
>> Best
>>
>> Carlos
>>
Re: About Statege3D in Flex
Posted by DarkStone <Da...@163.com>.
Hi Carlos,
The benefit of enabling Stage3D for Flex would be:
1. Much better performance on mobile devices.
2. Be able to develop Real 3D Apps and Games.
3. Making Flex the best cross platform native app developing SDK.
In fact you can use Stage3D directly in Flex Applications, Stage3D layers are below the Flex Application layer. But you can not take any advantages of Flex like MXML, Bindings, FXG, CSS etc. Cuz the current Flex is not design for the Stage3D kind of things.
In order to enable full support of Stage3D for Flex, it requires redesign Flex Framework from the ground up. Cuz Stage3D is about GPU rather than CPU, and the GPU Programming is quite different than CPU, you need to understand and deal with vertex, mesh, shader, texture, AGAL...
However there are still some feasible ways to enable Stage3D for Flex, here is one I thought of:
Redesign the Flex Framework by building it on top of the Starling Framework, this approach can reserve most of the Flex API names, for example UIComponent Class, FlexSprite Class etc. They are still the same class names and package names, but they need to extends the Starling Sprite Class instead of the original one. And of course, a simple extends Starling Sprite Class ain't gonna work, we will have to reimplement all of the subclasses, yes it's hell.
Anyway, unless someone can invest a million dollars on this, I don't think full Stage3D support for Flex will become reality in these years, although personally I want this so bad.
Sent from DarkStone's iPhone
在 2013-7-11，0:38，Carlos Rovira <ca...@apache.org> 写道：
> Hi,
>
> from time to time people comes with the desire to see Flex running on
> Stage3D. I would want to recopile all the state of the art info about this
> topic and see if is possible and how much work it would require.
>
> I know people like J.Campos did two attempts and get valious research from
> that experience. There's things to get into account like accessibility.
>
> Please could people share in this thread the things they know in order to
> recopile all info? Is there some things to take into account that could
> make Stage3D not possible for Flex? Could we overpass it and make it
> possible? If it would be possible...it will brings real benefits?
>
> If some work is done in this topic, I'd propose to make focused in this
> particular thing and unlike FlexJS, here I will not try to break
> UIComponent in small parts, or break compatibility. Even if it could be
> possible to have a global flag like "enableStage3D" to make our apps run on
> Stage3D if is true or remain in normal display layer, it could be great.
>
> Thanks in advance for any insight regarding this topic.
>
> Best
>
> Carlos
>
RE: About Statege3D in Flex
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Maybe store the summarized information in a page on our Wiki? Otherwise these emails could get pretty lengthy.
-Mark
-----Original Message-----
From: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] On Behalf Of Carlos Rovira
Sent: Wednesday, July 10, 2013 12:38 PM
To: dev@flex.apache.org
Subject: About Statege3D in Flex
Hi,
from time to time people comes with the desire to see Flex running on
Stage3D. I would want to recopile all the state of the art info about this
topic and see if is possible and how much work it would require.
I know people like J.Campos did two attempts and get valious research from
that experience. There's things to get into account like accessibility.
Please could people share in this thread the things they know in order to
recopile all info? Is there some things to take into account that could
make Stage3D not possible for Flex? Could we overpass it and make it
possible? If it would be possible...it will brings real benefits?
If some work is done in this topic, I'd propose to make focused in this
particular thing and unlike FlexJS, here I will not try to break
UIComponent in small parts, or break compatibility. Even if it could be
possible to have a global flag like "enableStage3D" to make our apps run on
Stage3D if is true or remain in normal display layer, it could be great.
Thanks in advance for any insight regarding this topic.
Best
Carlos
Re: About Statege3D in Flex
Posted by Avi Kessner <ak...@gmail.com>.
One thing you need to worry about when using starling is that the
eventdispatcher api is different. Starling does not allow 'weakl
isteners' or more accurately, only allows them. Meaning the method
signature is different.
On 11 Jul 2013 18:27, "Carlos Rovira" <ca...@codeoscopic.com> wrote:
> Hi,
>
> many thanks to all responses. Very useful info, thoughts and discussion.
>
> As we learn and think about new enhancements and evolutions of the actual
> flex sdk, more difficult is to get viable solutions that make it backwards
> compatible with the existing codebase of flex projects. I'd like the idea
> of actual SDK going Stage3D but I think we would end with a frankenstein
> that breaks compatibility and that will defeat the effort.
>
> For what you guys sugest here, it seems that the best place to try to get
> Stage3D support is in FlexJS. So we could try to introduce Starling here
> and setup the initial bricks and see how far we reach, due to the fact that
> FlexJS SWF version is already very basic, and hope that the projects that
> Om mentioned would come by the way at some time in the future.
>
> This will make FlexJS even more desirable since we well get HTML output and
> SWF GPU.
>
> I'll make more research about this topic in the following weeks as time
> permits and will report if I get something valuable.
>
>
>
> 2013/7/10 jude <fl...@gmail.com>
>
> > Hi Carlos,
> >
> > On first and second and third glance there seems to be a couple of ways
> to
> > go about this.
> >
> > 1. Replace Flash Display List with Starling Display List at compile time.
> > We would create an alternative set of classes that had the same method
> and
> > property signature as DisplayObjects and DisplayObjectContainers. Any
> > instances where flash.display.DisplayObject was declared would have to be
> > replaced by starling.display.DisplayObject. This could be done in the
> > compiler and set with a flag.
> >
> > This may be a lot of work or a 80 / 20 type of thing. Where 80% is free
> off
> > the bat and we spend much more time getting the remaining 20%. It depends
> > on how much Starling matches API wise. A simple DisplayTree test such as
> Om
> > suggested would give an initial idea of the amount of work.
> >
> > The cons are that it would require compiler work and the classes to match
> > 1:1. Although, we may be able to do a search and replace of the SWF after
> > the fact rather than at compile time. Jangeroo may be doing something
> like
> > this for replicating drawing calls on the JavaScript side.
> >
> > 2. Create an abstraction layer for rendering. At startup register the
> class
> > you want to use for rendering in the SingletonManager. All visual calls
> > would go through that at their last step. The pros are a hot swappable
> > rendering layer and possibly little to no compiler work. This would
> require
> > tens of thousands of lines of code changes and may introduce complexity
> in
> > testing and debugging.
> >
> > 3. Add in a flag at native display list junction points to proxy drawing
> to
> > the Starling DisplayList. All display objects are added by addChild call.
> > So in the root base class right before native call we check for a
> preferred
> > rendering target.
> >
> > /**
> > * @private
> > * This method allows access to the Player's native implementation
> > * of addChild(), which can be useful since components
> > * can override addChild() and thereby hide the native
> implementation.
> > * Note that this "base method" is final and cannot be overridden,
> > * so you can count on it to reflect what is happening at the player
> > level.
> > */
> > mx_internal final function
> $addChild(child:DisplayObject):DisplayObject
> > {
> > return FlexGlobals.toStarling ?
> FlexGlobals.starling.addChild(this,
> > child) : super.addChild(child);
> > }
> >
> > The cons to this are many including possibly duplicate display list,
> > dispatching events, etc. The graphics calls would also have to be patched
> > and have to be done in skins and it's unclear how to handle FXG etc. This
> > would be more of a test than a long term solution but would have smaller
> > bite size steps and immediate results. I also bring up this option
> because,
> > for me, in big projects like this the ability to see small incremental
> > results usually inspires me to continue it to the next step.
> >
> > My two cents
> >
> > On Wed, Jul 10, 2013 at 11:38 AM, Carlos Rovira <carlosrovira@apache.org
> > >wrote:
> >
> > > Hi,
> > >
> > > from time to time people comes with the desire to see Flex running on
> > > Stage3D. I would want to recopile all the state of the art info about
> > this
> > > topic and see if is possible and how much work it would require.
> > >
> > > I know people like J.Campos did two attempts and get valious research
> > from
> > > that experience. There's things to get into account like accessibility.
> > >
> > > Please could people share in this thread the things they know in order
> to
> > > recopile all info? Is there some things to take into account that could
> > > make Stage3D not possible for Flex? Could we overpass it and make it
> > > possible? If it would be possible...it will brings real benefits?
> > >
> > > If some work is done in this topic, I'd propose to make focused in this
> > > particular thing and unlike FlexJS, here I will not try to break
> > > UIComponent in small parts, or break compatibility. Even if it could
> be
> > > possible to have a global flag like "enableStage3D" to make our apps
> run
> > on
> > > Stage3D if is true or remain in normal display layer, it could be
> great.
> > >
> > > Thanks in advance for any insight regarding this topic.
> > >
> > > Best
> > >
> > > Carlos
> > >
> >
>
>
>
> --
> Carlos Rovira
> Director de Tecnología
> M: +34 607 22 60 05
> F: +34 912 94 80 80
> http://www.codeoscopic.com
> http://www.directwriter.es
> http://www.avant2.es
>
Re: About Statege3D in Flex
Posted by Carlos Rovira <ca...@codeoscopic.com>.
Hi,
many thanks to all responses. Very useful info, thoughts and discussion.
As we learn and think about new enhancements and evolutions of the actual
flex sdk, more difficult is to get viable solutions that make it backwards
compatible with the existing codebase of flex projects. I'd like the idea
of actual SDK going Stage3D but I think we would end with a frankenstein
that breaks compatibility and that will defeat the effort.
For what you guys sugest here, it seems that the best place to try to get
Stage3D support is in FlexJS. So we could try to introduce Starling here
and setup the initial bricks and see how far we reach, due to the fact that
FlexJS SWF version is already very basic, and hope that the projects that
Om mentioned would come by the way at some time in the future.
This will make FlexJS even more desirable since we well get HTML output and
SWF GPU.
I'll make more research about this topic in the following weeks as time
permits and will report if I get something valuable.
2013/7/10 jude <fl...@gmail.com>
> Hi Carlos,
>
> On first and second and third glance there seems to be a couple of ways to
> go about this.
>
> 1. Replace Flash Display List with Starling Display List at compile time.
> We would create an alternative set of classes that had the same method and
> property signature as DisplayObjects and DisplayObjectContainers. Any
> instances where flash.display.DisplayObject was declared would have to be
> replaced by starling.display.DisplayObject. This could be done in the
> compiler and set with a flag.
>
> This may be a lot of work or a 80 / 20 type of thing. Where 80% is free off
> the bat and we spend much more time getting the remaining 20%. It depends
> on how much Starling matches API wise. A simple DisplayTree test such as Om
> suggested would give an initial idea of the amount of work.
>
> The cons are that it would require compiler work and the classes to match
> 1:1. Although, we may be able to do a search and replace of the SWF after
> the fact rather than at compile time. Jangeroo may be doing something like
> this for replicating drawing calls on the JavaScript side.
>
> 2. Create an abstraction layer for rendering. At startup register the class
> you want to use for rendering in the SingletonManager. All visual calls
> would go through that at their last step. The pros are a hot swappable
> rendering layer and possibly little to no compiler work. This would require
> tens of thousands of lines of code changes and may introduce complexity in
> testing and debugging.
>
> 3. Add in a flag at native display list junction points to proxy drawing to
> the Starling DisplayList. All display objects are added by addChild call.
> So in the root base class right before native call we check for a preferred
> rendering target.
>
> /**
> * @private
> * This method allows access to the Player's native implementation
> * of addChild(), which can be useful since components
> * can override addChild() and thereby hide the native implementation.
> * Note that this "base method" is final and cannot be overridden,
> * so you can count on it to reflect what is happening at the player
> level.
> */
> mx_internal final function $addChild(child:DisplayObject):DisplayObject
> {
> return FlexGlobals.toStarling ? FlexGlobals.starling.addChild(this,
> child) : super.addChild(child);
> }
>
> The cons to this are many including possibly duplicate display list,
> dispatching events, etc. The graphics calls would also have to be patched
> and have to be done in skins and it's unclear how to handle FXG etc. This
> would be more of a test than a long term solution but would have smaller
> bite size steps and immediate results. I also bring up this option because,
> for me, in big projects like this the ability to see small incremental
> results usually inspires me to continue it to the next step.
>
> My two cents
>
> On Wed, Jul 10, 2013 at 11:38 AM, Carlos Rovira <carlosrovira@apache.org
> >wrote:
>
> > Hi,
> >
> > from time to time people comes with the desire to see Flex running on
> > Stage3D. I would want to recopile all the state of the art info about
> this
> > topic and see if is possible and how much work it would require.
> >
> > I know people like J.Campos did two attempts and get valious research
> from
> > that experience. There's things to get into account like accessibility.
> >
> > Please could people share in this thread the things they know in order to
> > recopile all info? Is there some things to take into account that could
> > make Stage3D not possible for Flex? Could we overpass it and make it
> > possible? If it would be possible...it will brings real benefits?
> >
> > If some work is done in this topic, I'd propose to make focused in this
> > particular thing and unlike FlexJS, here I will not try to break
> > UIComponent in small parts, or break compatibility. Even if it could be
> > possible to have a global flag like "enableStage3D" to make our apps run
> on
> > Stage3D if is true or remain in normal display layer, it could be great.
> >
> > Thanks in advance for any insight regarding this topic.
> >
> > Best
> >
> > Carlos
> >
>
--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F: +34 912 94 80 80
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es
Re: About Statege3D in Flex
Posted by jude <fl...@gmail.com>.
Hi Carlos,
On first and second and third glance there seems to be a couple of ways to
go about this.
1. Replace Flash Display List with Starling Display List at compile time.
We would create an alternative set of classes that had the same method and
property signature as DisplayObjects and DisplayObjectContainers. Any
instances where flash.display.DisplayObject was declared would have to be
replaced by starling.display.DisplayObject. This could be done in the
compiler and set with a flag.
This may be a lot of work or a 80 / 20 type of thing. Where 80% is free off
the bat and we spend much more time getting the remaining 20%. It depends
on how much Starling matches API wise. A simple DisplayTree test such as Om
suggested would give an initial idea of the amount of work.
The cons are that it would require compiler work and the classes to match
1:1. Although, we may be able to do a search and replace of the SWF after
the fact rather than at compile time. Jangeroo may be doing something like
this for replicating drawing calls on the JavaScript side.
2. Create an abstraction layer for rendering. At startup register the class
you want to use for rendering in the SingletonManager. All visual calls
would go through that at their last step. The pros are a hot swappable
rendering layer and possibly little to no compiler work. This would require
tens of thousands of lines of code changes and may introduce complexity in
testing and debugging.
3. Add in a flag at native display list junction points to proxy drawing to
the Starling DisplayList. All display objects are added by addChild call.
So in the root base class right before native call we check for a preferred
rendering target.
/**
* @private
* This method allows access to the Player's native implementation
* of addChild(), which can be useful since components
* can override addChild() and thereby hide the native implementation.
* Note that this "base method" is final and cannot be overridden,
* so you can count on it to reflect what is happening at the player
level.
*/
mx_internal final function $addChild(child:DisplayObject):DisplayObject
{
return FlexGlobals.toStarling ? FlexGlobals.starling.addChild(this,
child) : super.addChild(child);
}
The cons to this are many including possibly duplicate display list,
dispatching events, etc. The graphics calls would also have to be patched
and have to be done in skins and it's unclear how to handle FXG etc. This
would be more of a test than a long term solution but would have smaller
bite size steps and immediate results. I also bring up this option because,
for me, in big projects like this the ability to see small incremental
results usually inspires me to continue it to the next step.
My two cents
On Wed, Jul 10, 2013 at 11:38 AM, Carlos Rovira <ca...@apache.org>wrote:
> Hi,
>
> from time to time people comes with the desire to see Flex running on
> Stage3D. I would want to recopile all the state of the art info about this
> topic and see if is possible and how much work it would require.
>
> I know people like J.Campos did two attempts and get valious research from
> that experience. There's things to get into account like accessibility.
>
> Please could people share in this thread the things they know in order to
> recopile all info? Is there some things to take into account that could
> make Stage3D not possible for Flex? Could we overpass it and make it
> possible? If it would be possible...it will brings real benefits?
>
> If some work is done in this topic, I'd propose to make focused in this
> particular thing and unlike FlexJS, here I will not try to break
> UIComponent in small parts, or break compatibility. Even if it could be
> possible to have a global flag like "enableStage3D" to make our apps run on
> Stage3D if is true or remain in normal display layer, it could be great.
>
> Thanks in advance for any insight regarding this topic.
>
> Best
>
> Carlos
>